473,326 Members | 2,111 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

security/obfuscation question

Hello all,
Our company is trying to write some code in C#/.NET that we don't want an
end user to be able to see. The algorithms are not that complex, but are
sensitive such that if a user could decompile them, they'd be able to bypass
alot of things we don't want them to bypass.
We've looked at some obfuscators and, although they make it more confusing,
they certainly don't make it impossible for someone to figure out if they
have enough time on their hands.
Because of that, we've turned to another option.

This is what we're thinking - please feel free to poke holes in it and tell
me i'm wrong.

First, we'll write the "sensitive" code in vanilla C++ and compile that into
a .dll file.
Then, we'll statically link that .dll file into a Managed C++ .dll file with
some more functionality. (we've read that static linking only works for C++
into Managed C++)
Last, we'll reference that .dll file from the main application (written in
C#) and access the functionality provided by it via normal means.

In addition to all this, we'll be signing all of our .NET assemblies using
normal signing procedures documented all over the web.

If i'm not mistaken, this will do two things.
1) The signing of the code, along with the versioning and things already
built-in, will prevent a user from replacing the Managed C++ .dll with their
own .dll that does other things we don't want.
2) By hiding the sensitive code in vanilla C++, which is then embedded in
the Managed C++ dll, we're making it near impossible for someone to
decompile the assembly and get to that information.
We haven't tested #2 yet to make sure it works (we've just read it has,
we're testing next). Does anyone know for sure that it does/doesn't work?

Are we on the right track here? Is there possibly another option available
to us?

Thanks in advance,

-T
Jul 21 '05 #1
9 1609
Hi Tim,

This isn't an exact answer to your question but I think it's worth
mentioning. If you ship your code, even native x86 code, it can be
decompiled by someone who knows what they are doing. Basically all you can
do is try to make the decompile process hard enough that people won't want
to do it.

Think of it like this, you have a really cool new laptop sitting in your
kitchen. If you leave your front door unlocked (ship an un-obfuscated
assembly) then anyone can just walk in and take your laptop. If you lock the
door and add a deadbolt (ship an obfuscated assembly) then it will now take
a more determined and more skilled thief to steal your laptop. Finally, if
you add a security system and hire someone to guard your laptop (ship native
x86 code) someone is going to have to REALLY want that laptop to go to the
trouble to try and steal it but it may still happen. It's just a matter of
how valuable the decompiled code is versus how much somebody wants it.

Hope this helps.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Hello all,
Our company is trying to write some code in C#/.NET that we don't want an
end user to be able to see. The algorithms are not that complex, but are
sensitive such that if a user could decompile them, they'd be able to bypass alot of things we don't want them to bypass.
We've looked at some obfuscators and, although they make it more confusing, they certainly don't make it impossible for someone to figure out if they
have enough time on their hands.
Because of that, we've turned to another option.

This is what we're thinking - please feel free to poke holes in it and tell me i'm wrong.

First, we'll write the "sensitive" code in vanilla C++ and compile that into a .dll file.
Then, we'll statically link that .dll file into a Managed C++ .dll file with some more functionality. (we've read that static linking only works for C++ into Managed C++)
Last, we'll reference that .dll file from the main application (written in
C#) and access the functionality provided by it via normal means.

In addition to all this, we'll be signing all of our .NET assemblies using
normal signing procedures documented all over the web.

If i'm not mistaken, this will do two things.
1) The signing of the code, along with the versioning and things already
built-in, will prevent a user from replacing the Managed C++ .dll with their own .dll that does other things we don't want.
2) By hiding the sensitive code in vanilla C++, which is then embedded in
the Managed C++ dll, we're making it near impossible for someone to
decompile the assembly and get to that information.
We haven't tested #2 yet to make sure it works (we've just read it has,
we're testing next). Does anyone know for sure that it does/doesn't work?

Are we on the right track here? Is there possibly another option available
to us?

Thanks in advance,

-T

Jul 21 '05 #2
As a slight aside, but also fairly related... is it possible to compile c#
code straight to native code (ie instead of having to develop the native
code in C++)?

"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...
Hi Tim,

This isn't an exact answer to your question but I think it's worth
mentioning. If you ship your code, even native x86 code, it can be
decompiled by someone who knows what they are doing. Basically all you can
do is try to make the decompile process hard enough that people won't want
to do it.

Think of it like this, you have a really cool new laptop sitting in your
kitchen. If you leave your front door unlocked (ship an un-obfuscated
assembly) then anyone can just walk in and take your laptop. If you lock the door and add a deadbolt (ship an obfuscated assembly) then it will now take a more determined and more skilled thief to steal your laptop. Finally, if
you add a security system and hire someone to guard your laptop (ship native x86 code) someone is going to have to REALLY want that laptop to go to the
trouble to try and steal it but it may still happen. It's just a matter of
how valuable the decompiled code is versus how much somebody wants it.

Hope this helps.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Hello all,
Our company is trying to write some code in C#/.NET that we don't want an end user to be able to see. The algorithms are not that complex, but are
sensitive such that if a user could decompile them, they'd be able to

bypass
alot of things we don't want them to bypass.
We've looked at some obfuscators and, although they make it more

confusing,
they certainly don't make it impossible for someone to figure out if they have enough time on their hands.
Because of that, we've turned to another option.

This is what we're thinking - please feel free to poke holes in it and

tell
me i'm wrong.

First, we'll write the "sensitive" code in vanilla C++ and compile that

into
a .dll file.
Then, we'll statically link that .dll file into a Managed C++ .dll file

with
some more functionality. (we've read that static linking only works for

C++
into Managed C++)
Last, we'll reference that .dll file from the main application (written in C#) and access the functionality provided by it via normal means.

In addition to all this, we'll be signing all of our .NET assemblies using normal signing procedures documented all over the web.

If i'm not mistaken, this will do two things.
1) The signing of the code, along with the versioning and things already
built-in, will prevent a user from replacing the Managed C++ .dll with

their
own .dll that does other things we don't want.
2) By hiding the sensitive code in vanilla C++, which is then embedded in the Managed C++ dll, we're making it near impossible for someone to
decompile the assembly and get to that information.
We haven't tested #2 yet to make sure it works (we've just read it has,
we're testing next). Does anyone know for sure that it does/doesn't work?
Are we on the right track here? Is there possibly another option available to us?

Thanks in advance,

-T


Jul 21 '05 #3
http://www.oreilly.com/catalog/dotne...chapter/ch02.p
df

I hope that would help a little bit.

IL is assembler for C# so NO, I hope I am not right
(you can pre-interpret-it though)

KK
-----Original Message-----
As a slight aside, but also fairly related... is it possible to compile c#code straight to native code (ie instead of having to develop the nativecode in C++)?

"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in messagenews:uA**************@tk2msftngp13.phx.gbl...
Hi Tim,

This isn't an exact answer to your question but I think it's worth
mentioning. If you ship your code, even native x86 code, it can be decompiled by someone who knows what they are doing. Basically all you can do is try to make the decompile process hard enough that people won't want to do it.

Think of it like this, you have a really cool new laptop sitting in your kitchen. If you leave your front door unlocked (ship an un-obfuscated assembly) then anyone can just walk in and take your laptop. If you lock
the
door and add a deadbolt (ship an obfuscated assembly)
then it will nowtake
a more determined and more skilled thief to steal your
laptop. Finally, if you add a security system and hire someone to guard your laptop (shipnative
x86 code) someone is going to have to REALLY want that
laptop to go to the trouble to try and steal it but it may still happen. It's just a matter of how valuable the decompiled code is versus how much somebody wants it.
Hope this helps.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
> Hello all,
> Our company is trying to write some code in C#/.NET that we don't wantan > end user to be able to see. The algorithms are not
that complex, but are > sensitive such that if a user could decompile them, they'd be able to
bypass
> alot of things we don't want them to bypass.
> We've looked at some obfuscators and, although they
make it more confusing,
> they certainly don't make it impossible for someone
to figure out if
they > have enough time on their hands.
> Because of that, we've turned to another option.
>
> This is what we're thinking - please feel free to
poke holes in it and tell
> me i'm wrong.
>
> First, we'll write the "sensitive" code in vanilla
C++ and compile that into
> a .dll file.
> Then, we'll statically link that .dll file into a
Managed C++ .dll file with
> some more functionality. (we've read that static
linking only works for C++
> into Managed C++)
> Last, we'll reference that .dll file from the main
application (written
in > C#) and access the functionality provided by it via
normal means. >
> In addition to all this, we'll be signing all of our .NET assemblies
using > normal signing procedures documented all over the web.
>
> If i'm not mistaken, this will do two things.
> 1) The signing of the code, along with the versioning
and things already > built-in, will prevent a user from replacing the Managed C++ .dll with their
> own .dll that does other things we don't want.
> 2) By hiding the sensitive code in vanilla C++, which
is then embeddedin > the Managed C++ dll, we're making it near impossible
for someone to > decompile the assembly and get to that information.
>
>
> We haven't tested #2 yet to make sure it works (we've just read it has, > we're testing next). Does anyone know for sure that
it does/doesn'twork? >
> Are we on the right track here? Is there possibly
another option
available > to us?
>
> Thanks in advance,
>
> -T
>
>


.

Jul 21 '05 #4
We as a team have discussed this.
Some of us are more inclined to allow the signing to do its job and let that
be.
Others think we need to hide the algorithms more than an obfuscator will
(obfuscators mess with the function calls, but the code in the functions
themselves is pretty easy to decipher).
If this scenario works, we can run with it fairly easy (the code already
exists in both C++ and C#), we're just trying to see if this is
viable/possible.
Thanks for the input though,

Tim

"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...
Hi Tim,

This isn't an exact answer to your question but I think it's worth
mentioning. If you ship your code, even native x86 code, it can be
decompiled by someone who knows what they are doing. Basically all you can
do is try to make the decompile process hard enough that people won't want
to do it.

Think of it like this, you have a really cool new laptop sitting in your
kitchen. If you leave your front door unlocked (ship an un-obfuscated
assembly) then anyone can just walk in and take your laptop. If you lock the door and add a deadbolt (ship an obfuscated assembly) then it will now take a more determined and more skilled thief to steal your laptop. Finally, if
you add a security system and hire someone to guard your laptop (ship native x86 code) someone is going to have to REALLY want that laptop to go to the
trouble to try and steal it but it may still happen. It's just a matter of
how valuable the decompiled code is versus how much somebody wants it.

Hope this helps.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Hello all,
Our company is trying to write some code in C#/.NET that we don't want an end user to be able to see. The algorithms are not that complex, but are
sensitive such that if a user could decompile them, they'd be able to

bypass
alot of things we don't want them to bypass.
We've looked at some obfuscators and, although they make it more

confusing,
they certainly don't make it impossible for someone to figure out if they have enough time on their hands.
Because of that, we've turned to another option.

This is what we're thinking - please feel free to poke holes in it and

tell
me i'm wrong.

First, we'll write the "sensitive" code in vanilla C++ and compile that

into
a .dll file.
Then, we'll statically link that .dll file into a Managed C++ .dll file

with
some more functionality. (we've read that static linking only works for

C++
into Managed C++)
Last, we'll reference that .dll file from the main application (written in C#) and access the functionality provided by it via normal means.

In addition to all this, we'll be signing all of our .NET assemblies using normal signing procedures documented all over the web.

If i'm not mistaken, this will do two things.
1) The signing of the code, along with the versioning and things already
built-in, will prevent a user from replacing the Managed C++ .dll with

their
own .dll that does other things we don't want.
2) By hiding the sensitive code in vanilla C++, which is then embedded in the Managed C++ dll, we're making it near impossible for someone to
decompile the assembly and get to that information.
We haven't tested #2 yet to make sure it works (we've just read it has,
we're testing next). Does anyone know for sure that it does/doesn't work?
Are we on the right track here? Is there possibly another option available to us?

Thanks in advance,

-T


Jul 21 '05 #5
As an option, you may want to take a look of our
Salamander .NET protector, it prevents .NET disassembly
and decompilation by replacing MSIL with x86 machine code.

http://www.remotesoft.com/salamander/protector.html
(the protected code still requires .NET framework,
strings and resources can also be protected)

We are also working on a native compiler that links and
converts .NET assemblies to native image, .NET framework
is not required.

more info on the first part, the linker and mini-
deployment tool, is available here:
http://www.remotesoft.com/linker/

This linker is also capable of constructing a bare
minimum set of .NET framework to ship with your product,
so the client machine does not have to install the whole
framework. A typical windows app usually results in a 5MB
zip file, which can be unzipped and run without further
installation. Samples are provided on the web.

Thanks,

Huihong
Remotesoft
-----Original Message-----
Hello all,
Our company is trying to write some code in C#/.NET that we don't want anend user to be able to see. The algorithms are not that complex, but aresensitive such that if a user could decompile them, they'd be able to bypassalot of things we don't want them to bypass.
We've looked at some obfuscators and, although they make it more confusing,they certainly don't make it impossible for someone to figure out if theyhave enough time on their hands.
Because of that, we've turned to another option.

This is what we're thinking - please feel free to poke holes in it and tellme i'm wrong.

First, we'll write the "sensitive" code in vanilla C++ and compile that intoa .dll file.
Then, we'll statically link that .dll file into a Managed C++ .dll file withsome more functionality. (we've read that static linking only works for C++into Managed C++)
Last, we'll reference that .dll file from the main application (written inC#) and access the functionality provided by it via normal means.
In addition to all this, we'll be signing all of our .NET assemblies usingnormal signing procedures documented all over the web.

If i'm not mistaken, this will do two things.
1) The signing of the code, along with the versioning and things alreadybuilt-in, will prevent a user from replacing the Managed C++ .dll with theirown .dll that does other things we don't want.
2) By hiding the sensitive code in vanilla C++, which is then embedded inthe Managed C++ dll, we're making it near impossible for someone todecompile the assembly and get to that information.
We haven't tested #2 yet to make sure it works (we've just read it has,we're testing next). Does anyone know for sure that it does/doesn't work?
Are we on the right track here? Is there possibly another option availableto us?

Thanks in advance,

-T
.

Jul 21 '05 #6
KrisK <kk@easylink.com> wrote:
IL is assembler for C# so NO, I hope I am not right


Just to correct this slightly: IL is an assembler for .NET. It's not C#
specific in any way.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #7
Will,
This is a definite no-no I'm afraid. C# is 100% managed and HAS to be run
within the runtime.

HTH
Kieran

"Will Clark" <wi***@btopenworld.com> wrote in message
news:bj*********@sparta.btinternet.com...
As a slight aside, but also fairly related... is it possible to compile c#
code straight to native code (ie instead of having to develop the native
code in C++)?

"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...
Hi Tim,

This isn't an exact answer to your question but I think it's worth
mentioning. If you ship your code, even native x86 code, it can be
decompiled by someone who knows what they are doing. Basically all you can
do is try to make the decompile process hard enough that people won't want to do it.

Think of it like this, you have a really cool new laptop sitting in your
kitchen. If you leave your front door unlocked (ship an un-obfuscated
assembly) then anyone can just walk in and take your laptop. If you lock the
door and add a deadbolt (ship an obfuscated assembly) then it will now

take
a more determined and more skilled thief to steal your laptop. Finally, if you add a security system and hire someone to guard your laptop (ship

native
x86 code) someone is going to have to REALLY want that laptop to go to the trouble to try and steal it but it may still happen. It's just a matter of how valuable the decompiled code is versus how much somebody wants it.

Hope this helps.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Hello all,
Our company is trying to write some code in C#/.NET that we don't want an end user to be able to see. The algorithms are not that complex, but are sensitive such that if a user could decompile them, they'd be able to

bypass
alot of things we don't want them to bypass.
We've looked at some obfuscators and, although they make it more

confusing,
they certainly don't make it impossible for someone to figure out if they have enough time on their hands.
Because of that, we've turned to another option.

This is what we're thinking - please feel free to poke holes in it and

tell
me i'm wrong.

First, we'll write the "sensitive" code in vanilla C++ and compile that into
a .dll file.
Then, we'll statically link that .dll file into a Managed C++ .dll
file
with
some more functionality. (we've read that static linking only works
for C++
into Managed C++)
Last, we'll reference that .dll file from the main application

(written in C#) and access the functionality provided by it via normal means.

In addition to all this, we'll be signing all of our .NET assemblies using normal signing procedures documented all over the web.

If i'm not mistaken, this will do two things.
1) The signing of the code, along with the versioning and things
already built-in, will prevent a user from replacing the Managed C++ .dll with

their
own .dll that does other things we don't want.
2) By hiding the sensitive code in vanilla C++, which is then embedded

in the Managed C++ dll, we're making it near impossible for someone to
decompile the assembly and get to that information.
We haven't tested #2 yet to make sure it works (we've just read it has, we're testing next). Does anyone know for sure that it does/doesn't work?
Are we on the right track here? Is there possibly another option available to us?

Thanks in advance,

-T



Jul 21 '05 #8
Tim,

If you really think that it is necessary, I dont really see why this wouldnt
work as long as signing works correctly (unfortunately I've never tried this
so I can't comment). The unmanaged C++ code will be in pure unmanaged
machine code so it will be about has hard to decompile as you can reasonably
get.

HTH
Kieran

"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl...
We as a team have discussed this.
Some of us are more inclined to allow the signing to do its job and let that be.
Others think we need to hide the algorithms more than an obfuscator will
(obfuscators mess with the function calls, but the code in the functions
themselves is pretty easy to decipher).
If this scenario works, we can run with it fairly easy (the code already
exists in both C++ and C#), we're just trying to see if this is
viable/possible.
Thanks for the input though,

Tim

"Rob Windsor" <rw******@NO.MORE.SPAM.bigfoot.com> wrote in message
news:uA**************@tk2msftngp13.phx.gbl...
Hi Tim,

This isn't an exact answer to your question but I think it's worth
mentioning. If you ship your code, even native x86 code, it can be
decompiled by someone who knows what they are doing. Basically all you can
do is try to make the decompile process hard enough that people won't want to do it.

Think of it like this, you have a really cool new laptop sitting in your
kitchen. If you leave your front door unlocked (ship an un-obfuscated
assembly) then anyone can just walk in and take your laptop. If you lock the
door and add a deadbolt (ship an obfuscated assembly) then it will now

take
a more determined and more skilled thief to steal your laptop. Finally, if you add a security system and hire someone to guard your laptop (ship

native
x86 code) someone is going to have to REALLY want that laptop to go to the trouble to try and steal it but it may still happen. It's just a matter of how valuable the decompiled code is versus how much somebody wants it.

Hope this helps.

--
Rob Windsor
G6 Consulting
Toronto, Canada
"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
Hello all,
Our company is trying to write some code in C#/.NET that we don't want an end user to be able to see. The algorithms are not that complex, but are sensitive such that if a user could decompile them, they'd be able to

bypass
alot of things we don't want them to bypass.
We've looked at some obfuscators and, although they make it more

confusing,
they certainly don't make it impossible for someone to figure out if they have enough time on their hands.
Because of that, we've turned to another option.

This is what we're thinking - please feel free to poke holes in it and

tell
me i'm wrong.

First, we'll write the "sensitive" code in vanilla C++ and compile that into
a .dll file.
Then, we'll statically link that .dll file into a Managed C++ .dll
file
with
some more functionality. (we've read that static linking only works
for C++
into Managed C++)
Last, we'll reference that .dll file from the main application

(written in C#) and access the functionality provided by it via normal means.

In addition to all this, we'll be signing all of our .NET assemblies using normal signing procedures documented all over the web.

If i'm not mistaken, this will do two things.
1) The signing of the code, along with the versioning and things
already built-in, will prevent a user from replacing the Managed C++ .dll with

their
own .dll that does other things we don't want.
2) By hiding the sensitive code in vanilla C++, which is then embedded

in the Managed C++ dll, we're making it near impossible for someone to
decompile the assembly and get to that information.
We haven't tested #2 yet to make sure it works (we've just read it has, we're testing next). Does anyone know for sure that it does/doesn't work?
Are we on the right track here? Is there possibly another option available to us?

Thanks in advance,

-T



Jul 21 '05 #9
The way that I would approach it is to write your sensative algorithms as
win32 dll's and just use P/Invoke to access them directly with C#.

"Tim Mulholland" <ti*@eyeresponse.com> wrote in message
news:#u**************@TK2MSFTNGP12.phx.gbl...
Hello all,
Our company is trying to write some code in C#/.NET that we don't want an
end user to be able to see. The algorithms are not that complex, but are
sensitive such that if a user could decompile them, they'd be able to bypass alot of things we don't want them to bypass.
We've looked at some obfuscators and, although they make it more confusing, they certainly don't make it impossible for someone to figure out if they
have enough time on their hands.
Because of that, we've turned to another option.

This is what we're thinking - please feel free to poke holes in it and tell me i'm wrong.

First, we'll write the "sensitive" code in vanilla C++ and compile that into a .dll file.
Then, we'll statically link that .dll file into a Managed C++ .dll file with some more functionality. (we've read that static linking only works for C++ into Managed C++)
Last, we'll reference that .dll file from the main application (written in
C#) and access the functionality provided by it via normal means.

In addition to all this, we'll be signing all of our .NET assemblies using
normal signing procedures documented all over the web.

If i'm not mistaken, this will do two things.
1) The signing of the code, along with the versioning and things already
built-in, will prevent a user from replacing the Managed C++ .dll with their own .dll that does other things we don't want.
2) By hiding the sensitive code in vanilla C++, which is then embedded in
the Managed C++ dll, we're making it near impossible for someone to
decompile the assembly and get to that information.
We haven't tested #2 yet to make sure it works (we've just read it has,
we're testing next). Does anyone know for sure that it does/doesn't work?

Are we on the right track here? Is there possibly another option available
to us?

Thanks in advance,

-T

Jul 21 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: guitarromantic | last post by:
Hey everyone. I'm just finishing up writing a basic content management system, standard stuff really, just pulling info out of a database and allowing priveliged users to login and post it. I...
159
by: petantik | last post by:
Are there any commercial, or otherwise obfuscators for python source code or byte code and what are their relative advantages or disadvantages. I wonder because there are some byte code protection...
116
by: Mike MacSween | last post by:
S**t for brains strikes again! Why did I do that? When I met the clients and at some point they vaguely asked whether eventually would it be possible to have some people who could read the data...
32
by: Mike MacSween | last post by:
Further to 'Security - more complex than I thought' Has anybody ever seen any studies? Or anecdotal evidence? Done any studies themselves? Done any lab testing - you know - 10 users asked to get...
7
by: Tim Mulholland | last post by:
Hello all, Our company is trying to write some code in C#/.NET that we don't want an end user to be able to see. The algorithms are not that complex, but are sensitive such that if a user could...
5
by: Pete Davis | last post by:
This isn't directly a C# question, so I apologize for being somewhat off topic, but we have a project that is open source. When we release, the actual release builds will be obfuscated using string...
10
by: John T. | last post by:
Hi all Figure this scenario: - My Company develops an assembly (a controls DLL) - Since an obfuscation software is too expensive, my Company engages a consultant and delegates him the...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.