Can Basic4PPC .exe files be de-compiled?

[RB Smissaert]

As B4PPC is based on .Net is it easy to de-compile the .exe files, so can you get the source code from the .exe?
If that is the case I would have a problem and is there then a way to prevent this?

RBS

 

[Cableguy]

As far as I understand ...Yes, basic4ppc created exe files CAN be decompiled.....into pure c# as they are converted to it during compilation...
So it is NOT that easy to recreate a b4ppc project into a b4ppc file from an exe...
There are numerous way of trying to hide the guts of your code...
Some good coding pratices goes from basic "non-logical" naming of variables, to advanced "dummy" code, wich does nothing in the app it self, but puzzle the "Hacker"...

Aditionaly you can try "obfuscation" that implements some of the already known "good coding practices", in order to make the exe harder to read...

 

[RB Smissaert]

Yes, basic4ppc created exe files CAN be decompiled.....into pure c# as they are converted to it during compilation

OK, thanks. That is a serious problem then.

RBS

 

[RB Smissaert]

Given that Basic4PPC .exe files can be de-compiled to C# source code, how can you for example have database security?
Is it possible for B4P .exe files to use VB6 ActiveX .dll files on the device?
I guess not, but that would be a nice solution.

RBS

 

[Cableguy]

ActiveX controls CAN be used witha a wrapper dll..., the activeX itself will not be merged with the exe...

 

[agraham]

Basic4ppc legacy exes are difficult to decompile as they are tokenised to a proprietary format and interpreted by a bundled execution engine.

Basic4ppc optimised compiled exes are standard .NET assemblies containing IL (intermediate language) which is JITted (just in time compiled) by the .NET Framework to native code when run. The format of the IL is more or less independent of the language used to originally compile it so a C# original can be decompiled to VB.Net or Delphi for example, and vice versa.

The most famous (and free) decompiler is .NET Reflector .NET Reflector, class browser, analyzer and decompiler for .NET which is a very useful tool. Microsoft has left the whole .NET Framework open so that you can use Reflector to explore all the Framework assemblies and see how things work. There is at least one plugin to Reflector that can produce VS2005 Solutions that with a bit of tidying can be modified and recompiled - I have actually done this on a couple of occasions where the source code was not available.

There are several obfuscators, free and commercial, that you can use to remove unneeded information from your exes and mangle and encrypt variables names and strings to make things more difficult to reverse engineer. These are of varying quality in terms of their success in resistance to decompilation and commercial is not necessarily best. Google for "obfuscator" to find out more.

However I don't understand how "how can you for example have database security?" relates to this issue. A database file is language agnostic so, for example, a SQLite database file can be read by any program that can use SQLite data files whether .NET or native code.

 

[RB Smissaert]

Could you elaborate a bit? How could I use a VB6 dll that way?

Actually, I think the problem of DB security can be solved with the Crypto library. So, instead of having a stored unencrypted password and comparing that with the user input (password dialog) there would be a stored encrypted string that has to be decrypted with the user input (the password) and that decrypted string would then unlock the database. So, even if somebody would the encrypted string on the device it would be no harm.
Have I got this right?
What is the best crypto algo to use for this scenario?

RBS

 

[RB Smissaert]

a SQLite database file can be read by any program that can use SQLite data files whether .NET or native code.

Yes, but I can see 2 possible solutions.
1. Have an encrypted database. My VB wrapper can do that, but unfortunately the B4P SQLite wrapper can't do that and even if it could it wouldn't work with the encryption from the different VB wrapper. Also there would be a performance penalty with this approach.
2. Make the SQLite file (the db file) unreadable by writing some bytes to the file in the right places. Then on app start these bytes could be corrected and on app close these bytes could be put wrong again, so the file is un-usable.
This has no performance penalty, but if the .exe can be de-compiled to .net code then it will be easy to see what bytes are altered, so I need to store the byte locations and the byte numbers in an encrypted string. So, there is an encrypted password and an encrypted byte altering string.
All a bit complex, but it looks it is doable.

Simplest would be to have an external VB6 dll that does all the security as these dll's can't be decompiled.

RBS

 

[agraham]

So, instead of having a stored unencrypted password and comparing that with the user input (password dialog) there would be a stored encrypted string that has to be decrypted with the user input (the password) ... Have I got this right?

Ignoring wider questions as to how you protect the data in the database file it is standard security practice to NEVER decrypt a password. You should always store it encrypted and encrypt the users entry for comparison. The password security issue then becomes one of protecting the encryption key from compromise as well as enforcing the use of non-obvious passwords by users if they are allowed to choose their own.

What is the best crypto algo to use for this scenario?

The "scenario" is not described completely enough to comment. Security encompasses the entire application, its data, its environment, its potential user base and the threats that a security breach might produce. For pure password authentication use my re-implementation of the Unix Crypt in post #22 here http://www.b4x.com/forum/questions-help-needed/2214-base64-md5-crypt-ssl-basic4ppc.html might do.

Make the SQLite file (the db file) unreadable by writing some bytes to the file in the right places. Then on app start these bytes could be corrected and on app close these bytes could be put wrong again, so the file is un-usable.

A hex editor and comparison with a normal SQLite data file gets round that one easily enough!

Simplest would be to have an external VB6 dll that does all the security as these dll's can't be decompiled

Wrong I'm afraid. Not as easy as using Reflector on an un-obfuscated .NET assembly but still possible by using an X86 disassembler.

By the way, in case you are wondering, I can claim some experience in the security field as I have in the past done computer security work and supplied encryption based software/hardware solutions to two of the UKs clearing banks.

 

[RB Smissaert]

it is standard security practice to NEVER decrypt a password. You should always store it encrypted and encrypt the users entry for comparison.

OK, thanks, that makes sense.

The "scenario" is not described completely enough to comment.

Let me explain. This is clinical database, so it has patient data, diagnoses, drugs etc.
Security involves 2 situations: Somebody getting hold of the device and starting the application and seeing the data. Secondly, somebody getting hold of the device and copying the SQLite file and opening it in another application.

For pure password authentication use my re-implementation of the Unix Crypt in post #22

Will have a look at that.

A hex editor and comparison with a normal SQLite data file gets round that one easily enough!

Yes, agree with that, but couldn't see any better yet.

Wrong I'm afraid. Not as easy as using Reflector on an un-obfuscated .NET assembly but still possible by using an X86 disassembler.

My understanding was (but I am not an expert) that in practice it is near impossible to get anything useful out of an ActiceX dll.
Bear in mind that we are not dealing with something like the USA defence system here, so it is very unlikely that a top hacker gets to work on this.

I can claim some experience in the security field as I have in the past done computer security work and supplied encryption based software/hardware solutions to two of the UKs clearing banks.

Great. Let me know (off-list) if you are interested to do work on this for a fee. Maybe we can come to some arrangement.

RBS

 

[RB Smissaert]

A hex editor and comparison with a normal SQLite data file gets round that one easily enough!

Actually, this is true if you are overwriting the fixed bits of the file like the header, but it would be very difficult to restore the file if for example sqlite_master was overwritten.

RBS

 

[RB Smissaert]

Come to think of it, maybe there is a solution for this problem.
If it were possible to make a .net dll that uses my VB6 Active dll that is a SQLite wrapper (Olaf Schmidt's dhRichClient) then I could encrypt the actual database data on the desktop and decrypt on the device.
Would this be possible?

RBS

 

[RB Smissaert]

Is it possible to use Robert Simpson's .net wrappers for SQLite?
I understand they allow encryption.

RBS

 

[agraham]

Is it possible to use Robert Simpson's .net wrappers for SQLite?

Who? Where?

 

[RB Smissaert]

Putting Robert Simpson SQLite in Google will get you it at the first hit:
System.Data.SQLite

RBS

 

[agraham]

That's what the Basic4ppc SQL library uses, version 1.0.40.0 at the moment. I thought meant that you had found something else.

The encryption buillt-in to SQLite looks fairly easy to use WadeLiu Blog On Database: sqlite database encryption however the necessary calls to set and change the password are not exposed in the Basic4ppc SQL library. However it looks as though you can open an already encrypted database in Basic4ppc by passing the password in the connection string in Connection.Open(connectionstring) as described in the link so you could initialise and encrypt the database outside your Basic4ppc app on and it could happily use it with the correct password. Your problem then becomes that of managing that password as in the PM I sent you.

 

[RB Smissaert]

That's what the Basic4ppc SQL library uses, version 1.0.40.0 at the moment.

But can you use that exact file (the one on Robert Simpson's website) instead of the one that comes with the B4P installation? I asked a while ago and Erel answered that you can't do that.
The SQLite version of Robert's file is 3.6.3 and we are quite a few versions back from that, so I would like to update.

The other thing is that I make the SQLite DB file on the desktop with VBA/VB6 and I use a different wrapper, dhRichClient from Olaf Schmidt. Not sure now if I can encrypt with that and then decrypt with Robert's wrapper. Will have a look at this though.

RBS

 

[agraham]

But can you use that exact file (the one on Robert Simpson's website) instead of the one that comes with the B4P installation?

No, the Basic4ppc libraries are compiled to reference a specific version of System.Data.SQLite.dll. This is how .NET works, it is a .NET security consideration not a Basic4ppc limitation. I suppose you could compile your own versions of the libaries if you wanted to try a later version.

Not sure now if I can encrypt with that and then decrypt with Robert's wrapper

I can't see that the different wrappers would make any difference as long as the underlying SQLite implementations are compatible. Basic4ppc SQLite databases can be manipulated by other non-.NET SQLite tools and vice versa.

 

[RB Smissaert]

OK, thanks, will try it tonight. It all sounds promising.

RBS

 

[Erel]

The native library is a modified version of Robert's library.
A new version of this library will be available together with the next version of Basic4ppc.
It will not be a modified version so upgrades will be easier in the future.