Solved Recover accdb from accde

[Pat Hartman]

One of my clients sent me an .accde - "I think" since I can see the forms/reports/modules but I can't edit them and asked me to get back the code. I can't find my link to the tool or remember the site name. Can someone post it please. Thanks.

 

[Josef P.]

MDE to MDB Conversion - Retrieve VBA code from your MDE/ADE Databases

Convert your MDE applications back to MDB form, including VBA source code.

www.everythingaccess.com

BTW: check mde/accde: Database.Properties("MDE") = "T"

 

[Gasman]

One of my clients sent me an .accde - "I think" since I can see the forms/reports/modules but I can't edit them and asked me to get back the code. I can't find my link to the tool or remember the site name. Can someone post it please. Thanks.

Is it really that easy?

 

[Pat Hartman]

Is it really that easy?

It is. The old conversions used to be pretty terrible, usable only in a pinch because the variable names were meaningless. The newer ones actually recover the variable names also so the code reads pretty much as it was written.

Thanks Joseph.

 

[Gasman]

I had a Psion 3a app that I had reverse engineered many years ago, as the firm I bought the program from went bust.
The results were like that, generic variable names.

 

[isladogs]

Is it really that easy?

It is.

I think it would be helpful to anyone reading this thread if you both clarify what exactly you are both referring to here to avoid any possible misunderstanding.

Some additional info may be helpful here:
1. It is impossible to recover ACCDB files from ACCDE with the exception of specialist companies such as EverythingAccess

2. When an ACCDE (or MDE) file is created, the MDE property is created and set equal to T
The property value cannot then be changed to F ...so ACCDE creation cannot be reversed

3. By contrast, you can create the same property in an ACCDB file and doing so does restrict what can then be done
However in an ACCDB file the property value can be changed to F, thus removing those restrictions

Oops - how did that make an ACCDE file?

This article discusses a strange side effect of an ACCDE file being created when investigating an Access bug. It also acts as a warning to ALWAYS backup before making any changes

www.isladogs.co.uk

 

[Gasman]

For me it was the simple reverse engineering of the code.
However EverythingAccess states that they must be certain that the customer owns or has a legitimate claim to the DB.

 

[isladogs]

For ACCDE files, the process certainly isn’t simple. If it were, there would be many other companies offering a similar service, not all with the same sense of ethics.
By contrast, MDE files are relatively simple to reverse engineer.

 

[Pat Hartman]

I wasn't saying the process of recovery was trivial. I was saying that from my perspective, it is that easy. Send them the file, verify it is my code, and get the recovered code back. Someone else is doing the heavy lifting, not me

 

[isladogs]

LOL
I certainly agree with that!

 

[amorosik]

Knowing that the process of recovering code from an accde or mde is possible, how to make this process impossible?

 

[theDBguy]

Knowing that the process of recovering code from an accde or mde is possible, how to make this process impossible?

Not entirely preventable, but also from the same source company, it can be made much harder.

Code Protector for Microsoft Access - Protect the VBA source code from being reverse engineered from your MDE and ACCDE files

Code Protector - protect your MDE and ACCDE applications from reverse engineering.

www.everythingaccess.com

 

[The_Doc_Man]

Knowing that the process of recovering code from an accde or mde is possible, how to make this process impossible?

What Man can lock, Man can unlock. The word "impossible" doesn't exist if the .MDE or .ACCDE is still usable. If you study security theory documents, you will find that the various encryption schemes work to make things IMPRACTICAL to decrypt.

While I was with the U.S. Navy I held a security clearance and was required to study security, both theory and practice. I held a CompTIA Security+ certificate and acted as security officer for the systems assigned to me as systems administrator. My "Certified System Adminstrator" certificate also included security elements for my specific assigned systems. There is no such thing as an uncrackable system unless you consider systems so totally protected as to be useless in any practical sense. The only secure system is unplugged and sealed in layers of concrete with no connections to it.

A few systems exist that cannot be cracked in certain ways. For instance, no known hacks will crack an OpenVMS operating system through a network connection. But if you can get to it via hard-wired terminals, no guarantees. I mentioned that to illustrate that you CAN make something selectively uncrackable but you have to restrict its use to do so. With an Access-based system, that won't apply. You have to do the protecting at the operating system or network level. Unraveling the .MDE or .ACCDE format can be done, usually by someone who has signed many Microsoft Non-Disclosure Agreements regarding the innards of Access.

 

[gemma-the-husky]

Just an observation. Wayne (everythingaccess) sells a product that strips out all of the variable information that allows re-engineerig. If you use that then recovering the accdb code from the accde does not include the original variable names, so it's harder to use.

 

[Pat Hartman]

Hi all. I just wanted to report that my client's database was returned to me fully converted. Excellent job Wayne. Thanks EverythingAccess

 

[jdraw]

Great news Pat. Was there anything in the resulting accdb that was "unexpected"?
-- I'm thinking of the warning by Dave in #14.

All comments I've seen regarding Wayne and Everything Access are always positive.

 

[Pat Hartman]

Not really. I quickly went through the converted app with the .accde open side by side and connected to the same BE. Everything I checked worked correctly. I also did spot checks on the code with the other versions I have. There are differences and I haven't decided if I need to change anything yet. The names of GoSubs are not the original values and the arguments for message boxes are not carried forward either. Obviously, the comments are gone and the spacing is different.

Old Version:

Public Sub ShowFileListWithSubdirectories_JustList(sDir As String, sSearchString As String)
   Dim nDirs As Long
   Dim nFiles As Long
   Dim lSize As Currency
 
On Error GoTo Err_Proc
   If IsNull(sDir) Or IsNull(sSearchString) Then
        MsgBox "Directory and file type are both required", vbOKOnly + vbInformation
        Exit Sub
    End If
   
    ' Open recordset which will be used to add rows
    Set db = CurrentDb()
    Set qdDAO = db.QueryDefs!qCaptureEndorsementFileNames
    Set rsDAO = qdDAO.OpenRecordset

   lSize = FindFile_JustList(sDir, sSearchString, nDirs, nFiles)
   'MousePointer = vbDefault
   MsgBox Str(nFiles) & " files found in" & Str(nDirs) & _
          " directories", vbInformation
   MsgBox "Total Size = " & lSize & " bytes"
 
Exit_Proc:

   Set rsDAO = Nothing
 
   Exit Sub
Err_Proc:
    MsgBox Err.Number & "--" & Err.Description, vbCritical
    GoTo Exit_Proc
End Sub

Converted Version:

Public Sub ShowFileListWithSubdirectories_JustList(ByRef sDir As String, ByRef sSearchString As String)

   Dim nDirs  As Long
   Dim nFiles As Long
   Dim lSize  As Currency

   On Error GoTo ErrorHandler

   If IsNull(sDir) Or IsNull(sSearchString) Then

      MsgBox "Directory and file type are both required", vbInformation
      Exit Sub

   End If

   Set db = CurrentDb
   Set qdDAO = db.QueryDefs.Item("qCaptureEndorsementFileNames")
   Set rsDAO = qdDAO.OpenRecordset()
   lSize = FindFile_JustList(sDir, sSearchString, nDirs, nFiles)
   MsgBox Str(nFiles) & " files found in" & Str(nDirs) & " directories", vbInformation
   MsgBox "Total Size = " & lSize & " bytes"

ExitRoutine:
   Set rsDAO = Nothing
   Exit Sub

ErrorHandler:
   MsgBox Err & "--" & Err.Description, vbCritical
   GoTo ExitRoutine

End Sub

 

[isladogs]

The message box constant vbOKOnly is the default and has value=0. It is superfluous which is why it was removed when creating the ACCDE.

If you still had the original ACCDB, why did you need to have the ACCDE reverse engineered?

 

[Pat Hartman]

I needed the SPECIFIC version one of the clients is running. I have dozens of versions. Both specific client distributed releases and intermediate versions. The one version at this one client, I cannot find anywhere. I did have a hard drive meltdown and my guess is that whatever happened that afternoon, happened between backups to the cloud which were running every few hours at that time. Now I have them running continuously. This particular client has been using the same physical FE version since April of 2009. Pretty durned good if I do say so myself. No bug has ever been discovered. I did have to help them one time when they messed up their filing system and lost a bunch of scanned documents. I had to remove the rows from the table so they could "log" the scanned documents again. But that was a human error. And I've helped them move local servers twice. The app does exactly what the client needs. They don't want any of the new features so, they've never taken any updates. In 14 years, I doubt that I've billed them for more than 10 hours and that was mostly support for the hardware moves. Three of the 10 were two weeks ago. They have recently moved their entire Citrix environment to the cloud and now they're complaining about slowness in some queries so I when I went looking for the source and couldn't find it, i decided to have it rebuilt in case I needed to modify THAT version since the client still doesn't want any of the updates. I have better code for the task list form in newer versions so if I can't figure out what changed with SQL Server, I'll have to try the new version of that form. The recent move to the cloud cost them 3 hours of my time as I sat at attention and twiddled my thumbs but that was only because the DBA messed up the security and it took him 2:45 to get it fixed! Who knows what else happened with the database conversion. I guess I'm going to have to start by having him generate a script for me to recreate the database so I can compare it to what I think the BE should look like. Could be an index got dropped or maybe one is needed that didn't exist and the db only recently got big enough for it to be a problem.

I figured the missing attribute was probably the default so I wasn't worried about that. Since I actually maintain very few of the databases I build, I use a coding style that makes it as easy as possible for others to understand program logic. One of those "standards" is to always specify arguments clearly so no one ever has to remember what a default might be or get burned if a default changes.

I will probably go through and rename the GoSubs though since having those be funky names does interfere somewhat with readability. Doing the whole code base probably won't take more than a half hour. There just aren't that many of them.

 

[gemma-the-husky]

I always wondered whether reconstructing an accdb from an accde might "improve" it by structuring loops slightly differently, and so on.

Or maybe the first (pseudo) compilation to the accde applies some improvements which then get brought back to the accdb.

Wayne's accde secrecy tool strips out all of the variable names, so if a db gets reengjneered to source code it's rather less useful. Pat clearly didn't use that tool, or al the vars would come back as var1, var2 etc.