The easier way would be to download the program in a sandbox and then just open it using http://www.ollydbg.de/
At that point you can easily scan through for strings and determine what is going on. The best part is you can also put breakpoints in the executable so you could do partial runs to help gauge exactly how it works.
Where is OllyDbg64?
Its author Oleh Yuschuk has completely disappeared from the internet since the last update in February 2014. On his site, there are screenshots of a partial version of OllyDbg64 but it was never released to the public. Does anyone know more details about why the project was paused? Or has an alternative source for the partial version?
I used to do this years ago, back in the day on CS 1.4.
Essentially you need to scan memory registers related to the coordinates of an enemy player, typically you'd do that using a debugger, something like ollydbg. Somewhere in the games memory contains the x/y/z positions of all players on the screen, and once you find them, you can translate your mouse cursor to lock onto that position, relative to your own x/y/z position within the game window, or you could also check for a mouse collision with the visible parts of the screen, to make it fire when you manually move the mouse over the visible enemy (eg; soft aim). The same applies for wallhacks, you just draw an outline around the player, instead of moving the mouse to them.
When you've found the memory addresses that store the coordinates of players, you would load in a custom program as a DLL that takes care of that, and inject it into memory to add these extra features.
It's a lot harder now a days, as most games will involve memory randomization, and of course anti-cheat etc can be a hurdle.
There are other simpler methods that work in some games, such as color detection. If an object (eg; enemy player) has a unique color palette of sorts, you can simply scan each pixel on the screen for that unique color, and program the mouse to lock onto it.
But the DLL injection method is most common in the case of FPS games even today.
> Paper
I've been toying with the idea of using QR codes for denser and easier to reload paper storage. Not a unique idea, here is someone's musings about it. QR codes also have a large amount of error correction.
That link has a comment pointing to paperback which seems to be an attempt at making an efficient back up bitmap, though it seems to require a decent printer/scanner.
If you do just print it off without using fancy encoding stuff, I'd look into using a OCR font for easier scanning.
Edit:
And if you do go for paper backups, make sure you get acid free paper and store them in either acid free cardboard or (preferably) sealed boxes. Library of Congress on storage of paper
Why use a thumbdrive only? You could also burn it to a CD, and, if you want go even more hardcore, use Paperback to save the wallet file out to a paper copy (180K - 500K per page, depending on how high rez you want to go). Make sure you archive the executables for paperback someplace safe (but online). At that point, you have three kinds of media protecting your investment.
> I will say that many similar tools do contain enough source code as to count as derivative.
I could do the same thing CE does with a decompiler and memory scanner. It's nothing revolutionary nor does it contain anyones code, it just allows you to view asm and memory locations in ram of specific processes.
It's like using a magnifying glass, the magnifying glass does not contain what it views.
Edit: Here a good free one http://www.ollydbg.de/
Knowing C++ will do you no good, because the game has already been compiled down to machine code, and modifying machine code is very tricky. If you still want to do it, I strongly recommend using ollydbg. It will disassemble the machine code to assembler code, and then allow you to step through the assembler, just like a normal debugger. I think you can also use it to directly modify the machine code.
But do note that commercial games like Diablo often has countermeasures against debuggers like ollydbg, and it will cause such debuggers to crash. But note that indie often lack such countermeasures, though.
First learn the basic assembly instructions.
Then I suggest loading a simple program with ollydbg (http://www.ollydbg.de/) and seeing the execution of the assembly instruction. In fact, you can enter your own instructions and execute those. It also gives a good "graphical" presentation of the values of the current registers.
For a detailed explanation (and reference) the art of assembly is useful: http://www.arl.wustl.edu/~lockwood/class/cs306/books/artofasm/toc.html
> Would you use such a system?
Probably not because of all the inconveniences. The entire thing could be made better if the print was just a series of QR codes or something like http://www.ollydbg.de/Paperbak/index.html which is made to print any kind of data in machine readable form to paper. With a 600 dpi printer you can fit up to 500 kb onto a sheet of paper which makes it usable to send small binary files too.
I understand your lack of trust, as there's currently not much published about demonsaw to make it absolutely trustworthy.
And sorry, I meant disassembled, not decompiled (my bad).
If you want to check out demonsaw's every move first-hand, you could run it in a debugger (like OllyDBG).
Just to try to angle the trust/distrust: What made you trust other software you use that aren't open source? And is there anything alike demonsaw could do to appear more trustworthy except from open sourcing? (The reason why it isn't open sourced yet is explained here).
"OllyDbg is a 32-bit assembler level analysing debugger" http://www.ollydbg.de/
TibaneBackOffice.exe was an executable found in the leaked MtGox package. http://www.reddit.com/r/Bitcoin/comments/200k30/the_tibannebackofficeexe_executable_is_wallet/
OllyDbg is awesome & free, though I'm not a professional, I could definitely code you a nice virus (not that I would ever do such a thing) if you asked politely -- been studying reverse engineering for a few months now... so with those credentials in mind, here's the link.
Looks like you know the gist of it. I don't know much about assembly but I do know that x86 is going to be the most widely used out there and easiest to find information on. I learned MIPS in school using the emulator PCSpim/QtSpim. It is actually really simple and a good learning tool and since you skipped MIPS, it might be worth checking out to increase your knowledge.
To actually get your hands dirty, I would recommend actually disassembling some compiled code and working through it/modifying it. Use OllyDbg if you're working on Windows to disassemble and debug. You can see how you may "outcompile" the compiler this way. Maybe write some simple programs, compile them, and then disassemble them.
Also, you could search for some reverse engineering tutorials online. Assembly programming is essential to this type of work, which may not be kosher to some. Simply, cracking software can't be done without any functional knowledge of assembly, and it is usually x86.
> We need this problem solved because you can't trust everything to the cloud, but no one is making anything.
For absolutely critical data, you can always back up digital data to paper (Data -> Printer -> Paper -> Scanner -> Data).
This following program actually works well enough for small things like password databases and stuff. It might have been made as a joke by the author but it still seems to work:
Note: I make every effort to programatically figure out if links originally posted to Reddit are still good, but it's difficult.
If the original URL doesn't work, or has been replaced with something else, please help out by searching the Wayback Machine for the URL and posting a contemporary link if you find one. There's also a Chrome Extension which makes this process easy.
Is there a command in radare2 to log all single-stepped instructions to a buffer? And another command to single-step 30 instructions per second (Animate Over)? These two features are part of OllyDbg's Hit Trace. In Olly you can press numpad - and + to navigate back and forwards through instructions you (or the Animate Over command) executed. I'd be happy to code this if it doesn't exist already in radare2.
SECTION | CONTENT |
---|---|
Title | Should know Crack idm (internet download manager) With Ollydbg |
Description | Just Learn From Other OllyDbg File: http://www.ollydbg.de/odbg110.zip Should Known |
Length | 0:06:22 |
^(I am a bot, this is an auto-generated reply | )^Info ^| ^Feedback ^| ^(Reply STOP to opt out permanently)
You could try loading it into ollydbg which is a freeware software for disassembling exe programs. It shows the assembly language, but you should be able to locate the timer quickly and alter it, if the program is only 5mb in size.
IDA is the best there is for static analysis - but OllyDbg is quite good, especially if you get the right plug-ins for it. You can grab it at http://www.ollydbg.de/.
As for the algorithms, Cristina Cifuentes has written a ton of papers about reversing. One of her papers concerning various techniques can be found at http://www.zyloid.com/recomposer/files/decompilation_thesis.pdf.