Could hex editing a microsoft access db pass as data manipulation ?

[nIGHTmAYOR]

Could hex editing a microsoft access db pass as data manipulation ?
thats about it.

 

[gemma-the-husky]

what do you mean, data manipulation?

-----
if you edit anything in the IDE environment, you are changing the mdb on the disk

so if you made the same change in the file directly, you would get the same effect

but i suspect anyone would not find it easy to understand the mdb file structure enough to do it in that way.

 

[Banana]

Why don't you actually try it?

The unfortunate answer is yes, and data & code are stored plaintext. (in case of MDE, only data and constants are stored plaintext)

 

[georgedwilkinson]

So, there are no checksums or data integrity checks? Surely that can't be true.

 

[Banana]

Erm, I've actually read data, assumed that if I modified the data (within range), it'd accept the alterations outside the Access environment (and seem to think I saw some posts on internet supporting this) but never actually did that.

The only way to find out is to actually try it. I'll give it a whirl when I'm in front of the computer with Access on it. (If anyone else care to try, there's plenty of free hex editors out there- I use Cygnus.)

 

[Rabbie]

Why would you want to? Apart from the obvious reasons of changing data and avoiding audit trails and other security measures. I can see why you might want to read data if there had been corruption that made the DB unusable by Access.

 

[Banana]

Think malicious user trying to circumvent the ULS.

 

[georgedwilkinson]

Think malicious user trying to circumvent the ULS.

It is really hard to think that way. How bizarre.

 

[Banana]

It is really hard to think that way. How bizarre.

Care to elaborate on that?

If you meant that it was excessively paranoid, then yes, that may be true for most office workers who would think hex editors was something you used to edit witch's hex, but my viewpoint is that when building the threat model, you need to assess all possibilities and decide whether you want to invest your time & effort blocking so and so possibility, document the model so if there's a need to tighten the security the developers can refer to the documentation and know what you did and why.


BTW, I just opened one of sample lying with Notepad (not even a hex editor!) and was able to read several variables/data plaintext.

I edited one word (without changing the lenght) and indeed, the Access wouldn't open it, saying it was unrecognized format. This also seems to be permanent, and not fixed by C & R.

So, I guess I should revise my earlier answer- you certainly can read the data plaintext, but you can't edit it outside of Access without tripping some alarm.

 

[georgedwilkinson]

Care to elaborate on that?

Yes, I'm far too naive, obviously.

 

[Banana]

Yes, I'm far too naive, obviously.

Oh, no. You're a smart fellow and I've learned quite few from you.

Besides, I have no problem being called excessively paranoid and do appreciate any reality checks. For all I know, I could be just wasting my time chasing imaginary monsters when there is a much simpler way to implement security and not worry about the imaginary monster under my bed.

 

[nIGHTmAYOR]

interesting , comparing notepad to hex editors .. hmmm

ok let me put this straight , yes its possiable , how it failed with banana was merily because notepad converts control charachters to unicode font bu never mind that .

if u r intrested in another amazing fact you can do it while users are already connected to a database since access does not apply file locks for the fact that its a multi user platform.

finally the only draw back is that edited text must be of same length.

now my question remains. if a program was wrote to benefit from such a fact would it be authorized by microsoft ?

 

[Banana]

Ooo, forgot about the unicode representation. Will remember to try it with a hex editor and preserve the unicode representation.

As for your question-

If it's your data, I don't think Microsoft gives a darn. It's your data, after all. But for reverse engineering the binary to get a different output... I'm pretty sure they wouldn't appreciate that. EULA usually forbid reverse engineering or altering the binary.

 

[nIGHTmAYOR]

hmm so what if altering the binary was what matters ?

 

[Banana]

Then you would need to check your EULA. (you can get it by trying to re-install the Office 2003 and getting to the section asking you to agree... just read it and cancel once done or maybe there's EULA somewhere on Microsoft's site)

Exactly what do you want to do? Maybe it could be done via other routine using VBA?

 

[boblarson]

Then you would need to check your EULA. (you can get it by trying to re-install the Office 2003 and getting to the section asking you to agree...

No need for that. Just go to HELP > ABOUT and there's a link on the about dialog for VIEW END USER LICENSE AGREEMENT.

 

[Banana]

Cool. Thanks for that tidbit!

 

[nIGHTmAYOR]

simply cover a number of security holes by inserting invalied charachters on where they are triggered and reassigning original charachters on the need of use through an external hex editing api

 

[Banana]

Can you please go in details as I'm really curious about the 'security holes' and how altering the data externally would patch it?

Also, wouldn't it be easier to use a RDBMS backend that uses a daemon and thus the operating system security to protect the data?

 

[Banana]

Ah, I see.

It should be interesting project and I now understand why you weren't keen to share too much details.

Regarding the EULA & third party application that strips the "compiler junk", I would say that I'm (and the forum) is wrong place to ask this kind of question. Most of time and for most applications, altering binaries is generally frowned on. But it's very possible that MS's EULA is a bit different for Access than the majority. The best place to ask is to call Microsoft directly and ask them about that.

I've done that myself in past for a unrelated project and they were helpful in answering my questions about if I could use so and so alterations. The only shag is that you have to get transferred like five times before you get someone who can actually answer the question.

If the EULA doesn't address or is vague on those questions you have, it wouldn't hurt to call them up.