I am still regularly cracking the banking app from my bank to be able to run it on telephone.
They have decided to rage war against their users by checking for root, safenet and if google spyware framework is installed on android phone, so suddenly I wasn't able to get to my online banking and since one company software is handling all banks in my country (and I would rather stop using banks than start using google spyware ecosystem) they have forced me to remember of my youth and patch the .so in apks.
It was fun and I have to patch a new version every few releases but except from that, my online banking now works. :)
Doesn't safetynet prevent any and all kinds of tampering? I really hate how companies can just enforce that on your own device and you just have to take it.
I remember some multiplayer android games implementing the safetynet check client side and not passing it on to the server. I wouldn't expect a bank to make the same mistake.
They can check for a Google-signed "device integrity" response on the backend, and if they do, that's a game over. The "integrity" is checked by a TrustZone applet, which runs with higher privileges than the Android kernel and has access to the necessary keys.
Are there any “start here” guides for beginning reversing? Like a break it down Barney style? I’ve done some self study and shadowing teams at work but I need to fill in the gaps. Thanks!
Go to The Netherlands, go to Vrije Universiteit Amsterdam. Follow a course called "Binary and Malware Analysis" (if it's still called that). It's from the VUSec group. Follow: Hardware Security, Systems Security and Kernel Programming while you're at it ;-)
These were the hardest courses of my life.
That's all I know, I wish I had an easier answer. I happen to have lived there at the time. I was lucky in that regard for accidentally finding that course.
I can share what worked for me, although I am by no means a pro
I found the book "Reverse Engineering for beginners" quite useful. Its a bit tedious but if your serious about it and go through it a bit it'll give you some solid practice.
Also, write, compile, and reverse own snippets of your code to get more intuition about how things work.
Finally work on a actual target, not something crazy like Photoshop or Word but at least something real to get the practical experience. It might be a bit of a grind but when you do manage to crack/hack whatever it is your trying on, its an euphoric feeling
I learned by jumping head first into a program that used blowfish encryption to calculate a license and etc. the company was gone so this was the only option.
There is definitely a “clicks” moment. It took me three weeks from zero to key generator. Absolutely time worth spending.
As you can see in the other replies, there are many paths that lead to reverse engineering, but I feel like the best way to make the concepts stick is to have "reverse engineer X" be a problem standing in your way (where X is a piece of software, a protocol, etc.)
When you have that problem and you need to solve it, you have a target to throw all the "darts" those tutorials give you, and this will probably be more effective than just reading the material and hoping you'll use some of it in the future.
In my experience, you can learn reversing in an empirical fashion. Download Ghidra or IDA pro, and get cracking. Google every question you may have as you place breakpoints and modify control flow.
Or atleast that's how I got started as a midschooler with infinite time. Also try playing around with Cheat Engine. Don't let it's name fool you, it's a very advanced debugger that's capable to do way more than make you a bullet sponge :)
I consider that a feature, Java is always a pain since the applications always expect a system-wide JVM install but then are picky about which JVM they run on.
Thanks and you're absolutely right. It turns out tricks for reverse engineering to understand software help when you just want to understand software without reverse engineering also.
OllyDbg is more a debugger than a disassembler (although obviously it will show you disassembly as part of that process). The tools listed are more focused on exploring a binary and have more features to that end.
OllyDbg seems to have been replaces by x64dbg for most people I know
Yeah, I specifically mentioned interactive disassemblers here. There are only a few that let you fix up and annotate the disassembly or decompilation and they're leaps and bounds above the ones that don't.
“What do I do on long plane rides or while listening to the waves lap against the beach? Dead-listing.
Dead-listing is analyzing the raw disassembly of some target software and figuring it out using only pen and paper. This is great for vacations because your laptop won’t get sand in it. You usually have a long period of time to muse about the code in question without interruptions, something hard to find at home these days. And I’ve gotten some of my best ideas after setting aside my papers for a while and going for a long swim.”
It was a royal pain to lock windows up! It was clunky and you had to get a feel for if you were still in your program or you were dragged into the OS for things like Windows actual mouse code/logic.
I almost can’t imagine how I did it using another PC for my notes and scratchings. Having to manually type out so many addresses and the code I was inspecting.
Still, for some reason I loved SoftIce. I remember it just working.
Old games are really gaining new life with techniques like these. Games from 90s are still getting bug fixes and new content, such as "Caster of Magic" and "HoMM3 Horn of the Abyss"
This is a great guide. The “data is king” message is hard to overstate.
Some other bits and pieces not mentioned that could be helpful for beginners, from my own personal experience, that I hope show up in later parts:
• Know the calling convention[0] of the platform you are working on! If you don’t know where arguments come from or how values are returned from functions, you are not even going to be able to get started.
• In addition to working backwards from known system calls, embedded strings can also be a great place to start. They frequently contain filenames, error or debug messages, well-known magic values (PNG chunk identifiers, FourCC codes, file extensions, etc.), and other junk that can be used to identify potentially interesting functions. If you get really lucky and the binary uses some string-based message sending you will gain an enormous advantage this way.
• While I agree with the author that starting from `main` is mostly futile, it can still often be helpful to do a little bit there depending upon the kind of the binary you are reverse engineering. For example, GUI apps will generally have some initialisation code, then an event loop, then some teardown code. Identifying these sections is useful when you start looking at deeper functions to know if you are hitting a function that is called by init (more useful) or teardown (less useful) to make smarter choices on where to spend effort. The event loop will also use documented OS messages and types, so you can use those to get an idea of which system events map to which functions and what data they receive from the system, which again helps give useful context for deeper functions later on.
• Depending on the compiler or optimiser that was used, code within TUs may simply be emitted in sequence, so if you are disassembling some code and you can determine that a few functions next to each other are all member functions for the same C++ class, you can assume with high confidence that adjacent functions in other places also all operate on the same kind of object and create associations between groups of functions that way.
• Similar to the last point, looking for vtables in the data section of the binary can help to quickly learn about the size and fields of objects. If you see a sequence of function offsets, whatever function points to the start of that sequence is probably a constructor (and will likely use the offset like `mov [rax+0], offset <list of functions>`). The `malloc` call in the constructor or the constructor’s caller will tell the object size, and then reviewing all the vtable functions will let you fill out the object’s structure pretty easily.
• Notwithstanding “data is king”, knowing what code implementations of common data types look like can be very helpful. Once you know what it looks like to access a hash map, or traverse a linked list, or grow a vec, or get the length of a C-string, when you encounter that pattern, you immediately know what kind of object you’re working with.
• Understanding some of the optimisations that compilers use is also very helpful since they can look very weird, though this is more of a rote memorisation/exposure thing. Tools like Assembly x86 Emulator[1] can be super helpful when encountering confusing stuff since you can just paste in there, step through, and mess with the data/registers without needing to try to run a debugger on the original code.
• For whatever reason, the first few months I started reverse engineering I could not do it without using graph view. After that time, something shifted in my brain and now I can no longer work effectively without using a straight disassembly view most of the time. Pick what works for you, and just like an IDE, make sure to take time to configure your decompiler/disassembler with the visibility options that feel like they give you the strongest orientation.
The basic approach and difficulty curve for reverse engineering a binary is essentially the same as solving a jigsaw puzzle. Finding the corner pieces is simple, finding the edge pieces is harder, and finding the first pieces to connect to the edges is the hardest part. As you start filling in the picture, though, it becomes exponentially easier, so just keep at it.
Most of them work in the security industry and do:
* malware analysis (how does this malware work, how can it be detected, can we somehow decrypt data affected by this ransomware, are there any leads to who wrote this malware, etc)
* vulnerability research (finding and exploiting vulnerabilities in closed source software)
* assessment of closed source software (how secure is it, how does it work, does it have undocumented apis and how can those be used, etc.)
there is likely also a small market for analysis of competitor software, but I haven't seen this openly advertised yet.
There's also a pretty active academic scene for reverse engineering. The big thing right now (at least in the subfield I'm familiar with) is symbolic execution, where you generate a expression that shows the value of a variable at some point in time.
They have decided to rage war against their users by checking for root, safenet and if google spyware framework is installed on android phone, so suddenly I wasn't able to get to my online banking and since one company software is handling all banks in my country (and I would rather stop using banks than start using google spyware ecosystem) they have forced me to remember of my youth and patch the .so in apks.
It was fun and I have to patch a new version every few releases but except from that, my online banking now works. :)