Reverse Engineering

I've gotten into reverse engineering, have taught myself the basics of x86 assembly language, and have practiced with a few cracking tutorials. Now, for one of my uni courses, my professor provided the class with software that works with a USB license dongle, and I want to try to reverse engineer it. It's not for piracy purposes, since everyone in my course has their own dongle. I've done a bit of research into how the dongle works, but I still can't seem to get a starting point. Is there anything that could steer me in the right direction?

Attached: reverse-engineering-sized.jpg (650x400, 66K)

Other urls found in this thread:

lostdongle.com/tuts/Removing Sentinel SuperPro dongle from Applications.pdf
reddit.com/r/ReverseEngineering/comments/1sk43l/question_retrieving_ioctl_codes_from_a_driver/
docs.microsoft.com/en-us/windows-hardware/drivers/kernel/overview-of-the-windows-i-o-model
twitter.com/SFWRedditImages

Is it a USB dongle? Then use Wireshark to dump and look at the traffic.

Pls respond this is interesting I enjoy reverse engineering.

Yes, it's a Sentinel SuperPro/UltraPro USB dongle. I've read a tutorial paper on how it works and how to patch its APIs, and I understand it in theory, but my problem is I don't even know which executable to debug.

Well, the executable would probably interact with a driver, if it has it's own special driver and not just some generic USB interface. If it has it's own driver, I would try to disassemble the .sys file, and then look for patterns that match what you see in the dumps of the USB packets.

If it doesn't have it's own driver, I'm sure there's some generic set of instructions used to interact with Window's USB interface. Just look for that.

I've not really done any disassembly of x86, but in general, what I've laid out is kind of the tactic. Just dig into it. You'll find something eventually if you spend enough time on it :)

I have looked up exactly how this protection works, and the USB driver acts as a communication protocol between the application and the dongle. So the application sends queries to the dongle through the driver and the dongle gives the appropriate response. The problem is I don't know how to even start, like what to try disassembling.

Ahh.... Okay, I didn't fully understand what you were trying to reverse engineer. That could be tricky, depending on what kind of encryption it's using.

You're going to have to kind of map out an understanding of how things work between the various systems. So, what the driver handles vs what the program requests from the driver. Getting usb packet dumps will help with this, because you can use these as references when disassembling the driver. I would start with the driver's .sys file. Try to figure out how a Windows program can interact with a driver (in Linux it's through ioctls, not sure on Windows) and then try to find those kind of things in the driver. Map out all the possible inputs from programs, then find out where those inputs lead to as outputs.

I don't know if my experience is normal, but I would start out just disassembling the driver. Trace through the init. Then go from there. Chances are you'll find something, and with the packet data, you can piece something together.

Are there any links you can provide that might go deeper into what you're talking about? From what you're saying, I'm not even sure my approach to attacking this program is right. Based on the type of protection it's using and on a tutorial PDF I read up on this protection, I need to find and patch the APIs that perform the checks, which doesn't seem too hard, and then I need to simulate the dongle's memory into the program. The problem is that I tried disassembling the main program and I couldn't even find the relevant APIs.

Well, that's correct, you do need to patch where the checks are performed. I guess what I'm saying is an approach to actually understand the system beneath it all.

I never really read any books on reverse engineering, I've kind of just done it on my own, so if you have a book, it may be better than my own advice. I've also never done any sort of x86 debugging, but, I feel like with API's, there are symbols that you can latch onto if you know what the API that's being used is. That's just speculation.

Really, you're on the right track. But finding the points to patch is why I advocated understanding what's going on underneath of it all. There may be a faster track to getting to it, but that's out of my area of knowledge.

Sometimes, the way to fix it (i.e patching the apis) sounds simple, it's the actually work of finding them that becomes tedious. But, I don't know your exact situation.

I don't know if you've used IDA Pro, but the tutorial I read up on talked about using it to disassemble the included crackme, which was like a dongle verification program that I'm not sure if my program has, in order to find the APIs. So you're suggesting I should try to disassemble the USB driver? How would I go about doing that?

Hm... So, we're kind of delving into cracking territory instead of more generically reverse engineering. I've never really done any cracking. Whatever program you have that interacts with the dongle may have this verification program built into it, and you'll have to find it's routines within the program. I'm not really experienced in disassembly of x86 programs and patching them, I'm more experienced in reverse engineering in general.

So, you would find the .sys file of the driver that the USB device uses (this should be available by looking through device manager, not sure exactly where though) and then finding out how Windows programs can communicate with drivers. I've only ever worked with Linux drivers like I said earlier, and they use ioctls. You'll want to find these entries in the driver, where the program can communicate with the driver, and then see how this ends up communicating with the device. That's where having a dump of the packets comes in handy. You can kind of search through the disassembly to find things that resemble what the packets being sent and received look like.

Chances are, if you figure out how that whole system of program communicating with the driver works, you will be able to find these points inside of the program, where it communicates with the driver, and then trace these backwards/forwards to where the whole system of verification is handled.

I wish I had more experience with your actual issue, but I don't. I can really only offer more kind of generic reverse engineering approach advice.

I looked into the program's installation directory, and I found some executables with suggestive filenames, but when I ran them, they just opened and immediately closed a command prompt window. What was interesting to me was that when I ran the program by double clicking its icon without the dongle, it told me it couldn't find the dongle. When I ran it in a debugger, it told me it couldn't load a dll file.

Suggestive filenames as in they seemed to be verification programs.

Well, then that may be a good place to start. The program may call on those exe's somehow, I don't know enough to know how that would work. But, if that's the case, you probably have a lot less work as far as tracking down the verification part of it.

So I should just start with disassembling the .sys file of the driver and seeing how it works? I don't imagine I'll be able to crack it, but I figure it would be a good experiment.

If you want to understand how it works you could. I've heard of people doing it, but never done it myself.

Post a picture of the PCB of the dongle. Might be able to identify a specific chip on it if it is that advanced.


Have you used IDA pro to look at any of the binaries on it?

Unless it's some niggerlicious hardware shit it's probably just a weirdly formatted memory drive. Try imaging it with gparted?

>Post a picture of the PCB of the dongle
That would require me to take it apart? I don't want to do that because it's not mine. The dongle doesn't load anything either; if I plug it in, the program works, if I don't, it doesn't work. The only thing I can analyze is the main program.
It's a Sentinel SuperPro/UltraPro. It's kind of well-documented.

Are you using the guide at lostdongle.com/tuts/Removing Sentinel SuperPro dongle from Applications.pdf ? That pretty much explains everything I was saying earlier. What part of it are you stuck on?

Yeah, I am using that guide. I tried the plugin that would read .sig files with OllyDbg since I couldn't seem to find one that worked with x32dbg. When I tried using the plugin with the included dongleviewer_orig.exe crackme, I could find the Sentinel APIs (sproFormatPacket, sproFindFirstUnit, etc.). When I tried doing the same thing with my program, I couldn't find them. That's when I went through the files in the installation directory to see if there was some kind of license verification program, but I couldn't find anything.

Bump for the helpful user. I want to learn how to reverse engineer this.

Just looking at the time that PDF was made, 2006, I wouldn't be surprised if they've since moved away from that API. There might be a more recent tutorial, or you may have to discover the hooks yourself. That's what would be difficult. That guy did most of the groundwork in that tutorial.

Probably need to research about more recent API's or something, there may be forums dedicated to this kind of stuff.

If there is no recent tutorial, what should I try to find the hooks myself?

Well, like I said earlier, you're going to have to figure out what Windows uses when programs communicate with drivers. This will be your best bet when trying to narrow down what to disassemble. Looks like Windows has IOCTL's. This should provide an easier method to find the ins/outs of the verification protocol.

Here's a reddit post talking about it a bit more: reddit.com/r/ReverseEngineering/comments/1sk43l/question_retrieving_ioctl_codes_from_a_driver/

That PDF you are using kind of outlines it. You need to find the communication between program and driver, and then driver and device. Window's IOCTL's will give you that between the program/driver, and I'm sure there's a place in the driver where you can see what ioctl's are declared, giving you between driver/device.

I really can't provide much more help, because it's out of my area of expertise...

Also, to piggyback off my last post, it helps to understand the system of what you're trying to reverse engineer. Luckily, Microsoft has provided a lot of documentation for how their driver interface works: docs.microsoft.com/en-us/windows-hardware/drivers/kernel/overview-of-the-windows-i-o-model

I did some sound card driver reverse engineering through a virtual machine. With that, I figured out how the interface worked (it was Intel HD Audio, so there was a spec sheet detailing it) then I figured out what to capture and where to look. That's the biggest part, understanding what you're looking for and where to find it. Then, from there, doing whatever you need to do to either spoof it or patch it or whatever you plan on doing. So, if I were to put it into steps:

First, figure out what you're working with. A USB driver, a program, and a dongle. How does this program communicate with the driver? The Windows IRP system or whatever. Okay, now disassemble and look for those kind of calls, they will probably be some sort of uniform standard. Knowing where those are will get you close to the code that lets you know what the program wants to be returned in order to function.

Then, you need a way to communicate that data to the program so that those checks come back positive. Either spoofing the driver somehow, or modifying registers, I don't know much about cracking, but there is probably many different ways to trick the program into believing it's got the right data. If you can dump the data from the dongle you have now and somehow feed it to the program when it's not attached, I'm sure that would work too.

Mainly, since there doesn't seem to be a guide that can be followed, you'll have to actually understand it enough to know how it all works and not have the guide fill in the gaps. I don't know how experienced you are in programming, but even if you aren't very experienced, it's definitely learnable. You just have to stick at it.

Interesting. Are there any things I need to know besides assembly before to try this?

Hm... other than a basic understanding of how Windows programs interact with drivers, probably not really. Any sort of low-level programming is helpful, but not exactly necessary. Knowing how USB works would probably be helpful. Just research things as they come along if you don't understand them. There's a lot of helpful info on the internet. And, generally, people are willing to help as long as you seem like you're willing to put in the work.

OK, because I've taught myself some assembly and sort of know how to crack simple registration schemes, but that's as far as my reversing goes so far. I wonder if there are any dongle reversing forums.