I have a program (I own the rights) written in QuickBASIC 3.0, though I do not have anymore the source code.
Anyone know a decompiler that I can use to see what the program does?
Basically it gets some numbers in input and it performs some calculation, showing some results. Nothing too complicated.
Thanks
I haven't seen any publicly available tools but there's a page from a guy who claims to have made one. You could try contacting him.
I wouldn't recommend trying it on your own if you don't have any experience in reversing DOS programs. It seems QuickBASIC 3.0 was compiled into some kind of p-code. I've never seen any research on the DOS-era p-code, but it might bear some relation to the one eventually used in Visual Basic 6.0, and that one has been investigated quite a lot.
If you vaguely remember the idea but don't remember the details (e.g. actual values of coefficients in the formula), one thing you could try is to enter some numbers, read the results, and save them in an Excel sheet. Repeat that a couple of times and try to plot the data. Not much, but might help.
Use the debugger of Borland C++ 3.1, but you are going to need knowledge of assembler...
I’m trying to reverse engineer an old medical imaging format called Stentor for interoperability. It was designed by a company of the same name who was subsequently bought by Phillips. But Phillips has forgotten how to read Stentor files. I have a windows program which exports JPEG from Stentor files but it’s closed source. I’d like to automate this process in order to tackle hundreds of files in this format.
The program is late-1990s Win32 or MFC executeable. It runs next to an ActiveX (.ocx) file which I’ve been able to interop with, but that file doesn’t contain the export method. I'm looking for suggestions on how to dissemble the binary in order to unearth the algorithm used to convert Stentor to JPEG. I looked through the Stentor files in hex editor and didn’t find any evidence of JPEG (although hints on finding that would be appreciated too), so I think that the program has a couple of tricks up its sleeve.
Thanks in advance.
Kyle
Few programmers implement complex routines such as image recoding themselves. Instead they tend to license libraries that do that. A very smart way to start would be searching for text strings and see if you can discover the libraries they use. This will subsequently give you a lot of insight into how the data is encoded.
Another good strategy would be to build a program that simply runs the GUI of your export program by sending mouse and keyboard events directly to it. Let this run a few days to complete your export. Reverse engineering the file format is going to be slow and expensive so for a 1 time gig it's probably not worthwhile.
Any ideas ?
I think the original source was a goldmine database, looking around it appears that the file was likely built using an application called ACT which I gather is a huge product I don't really want to be deploying for a one off file total size less than 5 meg.
So ...
Anyone know of a simple tool that I can run this file through to convert it to a standard CSV or something?
It does appear to be (when looking at it in notepad and excel) in some sort of csv type format but it's like the data is encrypted somehow.
Ok this is weird,
I got a little confused because the data looked a complete mess, in actual fact the mess was the data, that's what it was meant to look like.
Simply put, i opened the file in notepad, seemed to have a sort of pattern so i droppped it on excel.
Apparently excel has no issues reading these files ... strange huh !!!
I am unaware of any third party tooling for opening these files specifically, although there is an SDK available for C# which could resolve your problem with a little elbow grease.
The SDK can be aquired for free Here
Also there is a developer forum which could provide some valuable resources including training material with sample code Here
Resources will be provided with the SDK
Also, out of interest since ACT is a Sage product have you any Sage software floating about which you could attempt to access the data with? Most offices have!
Failing all of the above there is a trial available for ACT! Here!
Good luck with your problem!
I wish to create shareware software that contains a registration algorithm. I am looking for a programming language, that cannot be easily decompiled into readable code. For example, C# can be decompiled into readable code.
What are my options?
Edit: I'm looking for something that can be only decompiled into assembly. Delphi, for example, cannot be decompiled like C# or Java, but from what I've heard, Delphi is dying.
Delphi is not dying, it is alive and well.
As is the community, at delphifeeds.
You can also see more delphi projects, Freeware, shareware and commercial at the Delphi Wikia.
Thus I'd say Delphi is a very good choice for Software Development. Freeware, Shareware or Commercial.
Update:
On September 1st 2011 Embarcadero released Rad Studio XE2. This released adds 64 Bit Compilation, Livebindings, Native Mac OSX compiling, IOS (via XCode) and a whole lot more to the already powerful delphi Dev environment.
If your CPU is able to see the code and run it, by definition, a sufficiently talented person can do it too.
You can, however, make it harder by running your code through an obfuscator.
I'd suggest the language of business and economics can protect your program.
If you are targeting consumers, and price it at say $10, almost all people would find it easier to pay you the $10 vs going into your program and reverse engineering it.
If you are targeting corporations, and say pricing it at $10,000, it just has to be easier to get the purchasing department to approve the payment than to reverse engineer your code. For real companies who would purchase your product, it's not worth the audit risk to have unlicensed code running.
Lastly, what are the costs/benefits of protecting your code? If you write your program in assembly instead of C#, you might have far higher production costs, while reducing the chance of reverse engineering. However, does this cost outweigh the potential lost sales? Could this time be better spent adding value for people who will buy the product? Generally, trying to sell your product to people who are never pay for software is not a economic strategy.
You could write it in Perl.
(I kid, I kid! Put down the pitchforks!)
As the others said, Delphi is NOT dying.
As the others said, there is no bulletproof method.
As the others said, there are tools to make the life of a cracker much harder.
But what the others didn't say is:
Java, .NET (etc.) obfuscation is rather a toy compared with obfuscation toys for eg. Delphi and other native solutions. (of course YMMV)
A very good technology to relatively protect your executable can be found here.
Repeat after me: "Obscurity is not security."
You would be better off using a hard encryption algorithm (where "hard" doesn't mean "difficult", but "not bi-directional; not easily reversible".
Isn't this logically impossible?
If you can run the code, you can get the instructions being executed by your CPU. At that point, your algorithm is readable, for some definitions of readable.
No language is capable of that AFAIK.. since it's impossible as it can always be reverse engineered.. though a good number of developers would cry if you coded it in brainfvck though.
"I'm looking for something that can be only decompiled into assembly."
Try writing your program in assembly. That is the best possible solution.
if you really concern about people disassemble your software, make your software as a service (SaaS) http://en.wikipedia.org/wiki/Software_as_a_service
Try finding an obfuscator. As the name suggests it obfuscates the code enough that reverse-engineering it will not be trivial.
Or use C/C++. Those can be disassembled, but that's it.
Of course, this is just enough to keep the not-sufficiently-competents from understanding and reverse-engineering the code.
As Dominic said, if you can run it, it can be decompiled.
That said, I believe there are tools that obfuscate the compiled code and make it more difficult for someone to disassemble and reverse or take apart a registration process.
For example, I believe that major companies like Adobe and Microsoft use products like this, in order to make it much more difficult for folks to disassemble and crack their programs.
It's like security or cryptography or even the locks on your car/house - someone with enough time and resources can probably break through anything.
You just need to tilt the curve enough to make it sufficiently unattractive for anyone to really try, so that they'd be more likely to move onto easier targets.
I am going to make the assumption that because you're writing shareware and you mention a registration algorithm you are wanting to protect your software from a keygen or patch that bypasses the restrictions on your trial versions.
Really the most you can do is deter. Like others have mentioned there are obfuscation techniques available, but they are not preventative. There are commercial software packers available which compress the file and make it initially unreadable. But the program has to be decompressed at some point so the machine can run it, so it's still reversible.
And that is pretty much the crutch against any of the anti-reversing techniques you'll see. It has to be interpreted by the machine at some point. More modern packers use anti-debugging techniques to deter the more novice reversers. But these techniques end up being documented rather quickly on popular reversing sites. Many of the techniques are bypassed with nothing more than a simple debugger plugin.
The only way I can think of to protect your executable from being arbitrarily reversed is to run the whole thing on a server you control and just pipe the output to users. But that's not always feasible.
As far as your language options go, take a loot at this. I can't really speak to how complete it is but I'm sure some others can add languages they think of.
If you're lookig "for something that can be only decompiled into assembly", that essentially means that you want to use a language that gets compiled (or assembled) directly into a native code executable.
The usual prime suspects then are C, C++, Delphi, VB6. Of course, also assembly meets your criteria, although I doubt you'd want to write any project of decent size in it.
Very simple:
No Programminglanguage,No Programm can Protect your Software.
The Software Cracker will reversengine your App till it is just asembler and will crackt it.
All code can be read back in assembly. Someone can reverse engineer your application and see what the machine is doing.
This is not so much a matter of choosing the right language as it is finding a tool that will do code obfuscation for you. Nothing is bulletproof, but there are efforts to accomplish this sort of thing.
Eg. see this research project about Java code obfuscation.
You can't be 100% sure nobody will able to read your code, but you can make it very hard. You can encrypt your code and modify it during run time.
For example I have not heard of any successful attempts to reverse engineering Skype.
You could always write it in APL. You could deliver the source and still no one would be able to understand it.
Any code running on client-side can be reverse engineered with enough trial and error. In my opinion, make the client-side code contain only the GUI code, while running the actual security requiring authentications etc. on serverside.
On the other hand, if your app's a service which runs on the client-side, such as a game, CAD, POS or anything that needs to have high quality code on the client-side, I'd recommend storing process outputs on your server-side with an encrypted upload tool, then authenticate the client's key/account data every-time before sending their data back? It is an overkill for most projects though.
I am working of a file preparation software to enable translators work easily and efficiently on a wide range of file formats.
As far as text-based formats (xml, php, resource files,...) are concerned, my small preparation utility works fine, but a major problem for most translators is to handle all kinds of proprietary binary formats (Framemaker, Publisher, Quark...).
These files are rarely requested and need to be opened in expensive applications (few freelance can afford to buy $20,000 worth of software just to handle a few projects per year), and even then it is not convenient to work directly in those applications anyway.
I would like to be able to read these files and extract the text in such a way that it can be translated and then re-imported in the original application with minimal effort, or even better, to recreate a valid native binary file.
Does that sound doable?
Where can I find more information on handling binary file formats and are there useful tools for these kind of jobs (besides regular hex editors)?
Thanks in advance.
Of course reverse engineering is possible, but without format specs it will take a lot of work. I would look at the return on effort regarding supporting these 'rarely requested, very expensive' formats. You may be better off spending that effort improving the core functionality of your app.
Another angle is to contact the companies with these formats, explain your goal, explain that it helps their product, and if they don't see you as competition they might be willing to help.
I know that you want to reverse engineer them - but since these may be propriety file formats you are looking at a very steep curve trying to decode them...
Some (as I have written some propritety formats for interal use before) have specific methods and objects written into them that serve some alternative process than the file contents themselves. Stuff that would prove the new file is illegal.
Just my 2 cents and I am no lawyer =>
Maybe you could pick a cheaper application which has import features for QuarkXPress. For example InDesign should be able to read Quark documents. Then use the importing application to export to whatever format you need - maybe with a help of plug-in.