3

This is my first post here (&hopefully not the last one!)

First of all, I gotta say I am no RE expert so I might sound a little confused.

So I have got a Delphi program consisting of two files (as far as you are concerned):

  • program.exe
  • program.bin

program.bin is a database the extraction of which is my final objective. By extraction I mean to have an original db file or something that is tangible and does not lack any information.

The program is a GUI application that does nothing except loading the database and showing it in two columns (at least this is what I see).

Project description

  • Language: Borland Delphi 6-7 (thanks to PEiD)
  • IDE used: RAD Studio (most probably)

What I did

  • I tried DeDe, but for some reason program.exe does not load fully (which I guess makes it harder to decompile).
  • I tried (almost) all of the BDE type of database viewers (paradox, dBase etc.). Why? because I found these strings while scrolling the assembly code in Olly. None of them were successful except one. Some of them crashed during the opening, others said it had incorrect headers. The one that worked was password recovery program that did not reject the file and, moreover, told me the password! :D.
  • I tried lots of filetype detector programs. All of them failed except for "File Analyzer" which told me for 99% accuracy[sic] that it was VisiCalc file, which c'mon can't be true xD.
  • I tried Process Monitor and saw that program.bin is read by chunks of 64 bytes. (not sure if this is useful information).
  • I also tried some famous analysis tools (idr, Olly) tried observing codes for hours, but as I am not knowledgeable I was not able use them.

Observations

  • Apart from that I spotted "paradox", "dBase" strings in the assembly, I also saw that it has some relation to cryptbase.dll, which led me thinking it might be encrypted, but surprisingly IDA does not list cryptbase.dll in the import list of libraries.
  • While inspecting the results of IDR I saw that program.exe has actually a dblogin form. If this really exists then it is invisible I guess.

So my question is what can I do? how can I place myself between the components so that I can see what it does?

P.S. I can put a link to the executable but I do not want to make it specific. I intend to acquire general techniques here.

NOTE: This is purely for educational purposes only, as I already have this database. What I did was basically dump the memory where the program placed its database. (BTW, is there any small tool for dumping specific range of memory? I used Win7's original dumper in the Task Manager)

Improve this question
2
  • I have no experience with delphi applications but I'ld do it the following way: If you identified the function(s) that accesses/reads from the file, you should start the application, attach a debugger like Olly, and put a breakpoint on that function. Then try to trigger it and from then follow the execution flow until you understand how it's done. If you have the raw bytes that it read from the file, put a break point on those bytes and identify what happens to those bytes, which function does the encryption/interpretation of the data. At least that's how I'ld do it :)
    – Dominik Antal
    Mar 23, 2015 at 14:14
  • @DominikAntal, no I have not identified yet. Like I said DeDe does not load it fully. Speaking of breakpoints, yes memory breakpoints is one good thing I haven't tried yet. I'll try putting a breakpoint on the address, whence I dumped the db and see if it sheds light on anything.
    – Gio Eufshi
    Mar 23, 2015 at 18:24

1 Answer 1

Reset to default
1

Not really an answer, but too long for a comment.

Your program might use LoadLibrary to load cryptbase.dll. Start Olly, place breakpoints on LoadLibraryA and LoadLibraryW and check what happens.

64 bytes (256 bits) is the input block size to various encryption algorithms. Your program might use one of these, either through cryptbase.dll, or compiled into the program. Check signsrch to see if your program contains any constants used by various encryption algorithms.

Remember Process Monitor can show you the stack to each API call it intercepts. If every read of 64 bytes originates from the same address in your .exe, but addresses further up the stack vary, the last common address is probably some read_and_decrypt() subroutine. This is a great place to place your breakpoints.

Sometimes, it's easier to let the original program do its job than to crack everything. Your program will probably use a function somewhere that adds one row to the table to be displayed. If you can find this function, you could create a detour that opens a file, appends the row data to it, and closes it.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.