z5164445-blog

[z5164445-blog]

Wrap Up: My Final Crack:

My goal for this project was to be able to use a trial software product as if I were using the full version, and in the case of WinRAR, that requires that I get rid of the pop ups that open at the launch of the program. I’ve found that there are three potential windows. One which is displayed the first time you open winRAR and is easily the largest popup. It briefly outlines trial ware and the responsibility of the customer. The next two pop up options seem to alternate randomly, on showing an add with flashing text stating that your trial has expired, or a smaller window that states that you are currently within the trial period. I’ve found that my demo solution causes a crash in the case of opening winRAR for the first time. This test case is pretty hard to test as I would have to uninstall and reinstall winRAR to get the potential pop-up to test differing solutions, so I took that as an acceptable loss. The second launch always goes off without problem, which is the main win.

Regardless of what combinations of NOP operations and logic diversion I  use when removing the two calls to Create_window (as shown in my demo), I always have a clean cracked launch. Removing the arguments to the function, as well as removing the class ‘REMINDER’ or ‘RAR_Reminder’ located elsewhere within the program caused a failure to launch.

Overall I’m happy with my Crack, and more importantly, I feel like I’ve made significant progress in understanding not only the x86 language, but gained a higher level understanding of lower level programming. I now recognize many variations of General Purpose Registers and how they can explain the context of a program. I have developed analytical skills which will help me in my security journey, and I find myself disassembling code for the fun of it. I got completely engaged with cpu architecture and OS theory that I may have largely abandoned my basic ‘Learn Linux’ ctf extensions. Even still, I would say that my Something Awesome project has been a huge success and I’ve now gotten a taste for self driven research as a result.

[z5164445-blog]

I was unzipping random trials to try and crack when I noticed my unzipper ‘WinRAR’ was in fact a good candidate to experiment on. I eventually found a crack that works and still allows full functionality of the program. 

Hope you enjoy :)

[z5164445-blog]

SA:So Close

I’m annoyed at Photoshop. I’ve found all these functions begging to be cracked and I still can’t find any reference in-program that tells me I’m using the trial version. I think I might have to switch program...

[z5164445-blog]

Lots of DLLs:

Upon a little research, I learnt that the product licensing logic is contained within amtlib.dll, a dll file (or a Dynamic-Link Library) being similar to an .exe, the difference being that a .dll is referencable by other dlls and exes but not directly executable in Windows. The Photoshop folder has loads of these DLLs, which makes sense as Photoshop is a massive program at a 1.5 GB size.

Throwing it into Binary Ninja, after about 5 minutes of analysis, I was greeted with roughly 1,655,684 different functions, very few of which had names, and none which hav ethe name main(). This is imaginably a side effect of optimisation. Maybe I’ve bitten off a little bit more than I can chew.

Furthermore, I’m not greeted by the “Trial Period” pop up I’m familiar with from middle school. This lack of anything to crack might be a bit of a roadblock.

[z5164445-blog]

SA Part 3: Getting Practical

The next part of my Something Awesome is cracking a piece of commercial software.

 Ive chosen Photoshop CS6, as it was a program I remember downloading a crack for in my middle school days so that I could use it for free. Now that I have access to a legitimate copy of Photoshop, I feel that trying to crack CS6 as a proof of concept is less sketchy.

After crawling the net trying to find somewhere I could still get my hands on the old PhotoShop CS6, I started my installation as a trial, and am ready to start de assembling some code!

[z5164445-blog]

0x07: Quick Math

Part One

This one was pretty tough mainly just due to my limited math ability. Starting off, we can see that a number is gotten from fgets: It is then checked for its length, which must be 7 characters long (including the null terminator\newline) which is then converted to a long.

Part Two

What happens next is a bit trickier. The program enters some sort of loop with what looks like an iterator I’ve named ‘i’. After converting the doubleword (32 bits) to a quadword (64 bits), a loop will be entered if ‘i’ is greater than our long password. A series of mathematical functions is called, such as cqo: which converts the RAX registers sign and puts it into every bit register of the RDX register, giving either 64 1’s or 0’s. idiv divides two numbers or in this case, divides RCX by RAX. The SAR intruction shifts bits to the right, shl shifts to the left. I’m not exactly sure what all this bit shifting and multiplication is doing but, after a the final result is checked against the password, it will either loop or exit the loop and set a byte value (which Ive named boolean)  to one, and then xor this boolean against 0x1. If the boolean is 0, then we get the our access.

Something to notes is that if our answer is negative, as long as it’s a five 7 character long string (inclusive of ‘-‘ and ‘\n’) then our boolean will never be set to 1 and we will get our access. Even a ‘-’ followed by five spaces satisfies the condition.

Brute force attack

Since I just learnt how to bash script I thought I’d see how a brute force attack went against the positive values. My script inputs every 6 digit combination of numbers and it appears the only valid positive codes were 000000, 000001, and 000002.

[z5164445-blog]

0x06: Random numbers

This one was interesting, the format was similar to previous ones, and after a while I figured that given a positive integer, my input would seed a random number generator. Given the unpredictability and uncertainty associated with getting this password, I used this exercise as an opportunity to learn bash scripting. This is what I came up with.

Combined with grep, I found the correct input to be 22.

[z5164445-blog]

0x05: WannaCry

This was definitely the toughest one yet, especially since the “https:” link didn’t lead anywhere. Similarly to the last exercise, this wasn’t hard to modify. However the use of curl isn’t something I’ve seen in a while and the repetitive usage of curl_set_opt() was extremely difficult to understand and follow, besides the fact that it was probably trying to load a website that doesn’t seem to exist. Looking at the source code gave me a slight understanding of the set_opt()’s but the memory_write_back() was also pretty cooked to look at. Maybe I was supposed to register the site to return something, but I’m still unsure. Def’s wannacry ☹

The use of a kill switch in a program seems like an interesting addition, I’m curious to how easily this would be discovered in a legitimate piece of malware, and what action would be taken. How fast can law enforcement or internet providers act to activate such a kill switch? Would WannaCry simply encrypt data indefinitely if not connected to the internet?

I’ll definitely be looking deeper into WannaCry and CryptoWorms in general 

[z5164445-blog]

0x04:

Has a subroutine but seems simple enough. Reads a file called “licence.txt” and compares the contents against the number 6447. Both forks call the fclose function, and one sets the AL register (our RAX registers little brother) to 1, which will return to the main function to determine the success of the license fetch. So all we need to do is create a text file with the string 6447 inside and we’re set.

Since the checkValid() is nice and contained I can simply convert the call to a ‘return 1’ statement and not need a license file.

Nice.

[z5164445-blog]

0x03:

Another instant failure, lets take a look inside. 

This is the first time I’ve seen getenv(), but it looks like the program scans for an environmental variable FLAG before checking against 0x1ab9 (6841 woot woot!).  Setting an environmental variable using export, we get a correct password when we run.

Getting rid of all references to the RAX (so I don’t have to set a FLAG environmental variable) and never branching gives us this monstrosity.

Surely there’s a better way than this.

[z5164445-blog]

0x02: General Purpose Registers

Assembly code has access to a computers registers and there is a standardized way to use each register. The RBP is the base pointer, which points to the base of a stack while the stack pointer (or RSP) points to the top of the stack. As we are using x86_64, we also have some other common registers such as the 64 bit registers such as the RAX (Register A Extended), RBX (Register B Extended) etc. which are volatile and subject during the life of a subroutine. You also have RSI (Register Source Index),  and the RDI (Register Destination Index), which are often used as argument registers when calling functions and are non-volatile, and if changed, must be first saved and reverted once returned. Most jump operations reference a FLAG register which has different values depending on function returns.  

It’s useful to know that these 64 bit registers can be separated into their smaller 32 bit, 16 bit and 8 bit counterparts and will often by referred as such if 64 bits of memory is excessive. This is denoted by a different starting letter, such as the first 32 bits of the RAX register becoming the 32 bit EAX register or the 16 bit AX register, becoming the AL register at  8 bits.

I feel like I’m starting to get the hang of how everything is working now, but that doesn’t make it easy to read.

Our next challenge immediately outputs an incorrect password at us, differing from the last two challenges.

From what I just said about the EDI and ESI being used as arguments, and the fact that main() uses them, we can infer that they are argc and argv[]. The check [IF ( EDI <= 1 ): branch to ‘password incorrect’] means we can assume its argc, and the program checks our password as an argument.

The second part does another STRTOL() operation, on argv[1], then compares it against 0x1dc7, or 7623. Changing the program to never branch, plus removing all references to argv[] and argc gives us a nice crack, even without an argument. However this feels cheap, as the code wasn’t elegantly changed but rather highly butchered to the point where I don’t feel great about my solution.

Nice-ish.

[z5164445-blog]

0x01. Let’s learn x86!

As we get through these challenges, it’s inevitable that I’ll actually have to know what I’m looking at. So what language am I looking at? What determines the language that Binary Ninja spits out at me?

After a bit of research, my rough understanding is that GCC will build according to your computers architecture. Almost all modern computers can support the basic x86 instruction set as it’s built for a 32 bit system, with 64 bit systems also able to utilize it. I found that the architecture I’m looking at is x86_64, also known as Intel 64 or x64, built for 64 bit architectures, and is overall more capable than its 32 bit counterpart. However I’m still struggling to find any examples of fgets and the other C functions being used in the same way they are in these examples, which makes it hard to understand what exactly is going on. However, I still persist.  

The output of the program is similar to the previous exercise, however with a new password.

However this time we’ve got a few more branches and less obvious solutions.

I can see that a strtol() operation is converting what I assume to be the password into an integer, which is then compared against 0x539, or 1337 in decimal. This elite number is probably the password. But that doesn’t matter when I can butcher the code to compare my password against my password in order to always branch to “password correct”

With our newly cracked code, we get a correct answer every time.

Nice.

[z5164445-blog]

SA: Part 2: Challenges

0x00. Familiar faces?

Starting off, I’m attempting Jazz’s Reverse engineering challenges, the first of the eight being 0x00, which behaves as follows

Now, I don’t know exactly whats going on but there are a few names I recognize such as fgets, strlen, strncmp and printf. However, unlike C, they don’t have any arguments on the same line. From a basic skimming I can understand that the program will input “Password correct!” if ‘asecurepassword’ is input.

This is tested through a call to the strncmp function. Otherwise it will jump to the instruction 0x11f7, or the “password incorrect.” branch. The simplest way I can see to get a correct password is to modify the strncmp to always return 0.

Reassembling the above, we get the following output.

Nice.

[z5164445-blog]

Something Awesome

Part 1: Into the Books

From watching Jazz’s seminar on cracking software and my limited memory of COMP1521, my basic understanding of reverse engineering a C file is this:

Compilation + Assembly:

Firstly, Your C code (which is basically a fancy text file) is put through a compiler. The two most common linux C compilers are GCC ( the GNU Compiler Collection) and CLANG, of which I will be using GCC. This compiler converts your C code into assembly code (.s file) which will be the main code I will be focusing on for this project.

This compilation process cannot be cleanly reversed. Once you compile your C code, the compiled file you now have can be reversed to create C that is functionally the same as your original code, but this does not mean it will be similar to your OG code,  or even cleanly readable at all.

Once compiled, The assembler will then turn your new assembly code into object code (.o file), which via a link editor will be turned into an machine code in the form of an executable file (.exe file) which the computer can run.  

Disassembly:

This is the process of reversing the assembly process, ie. Creating semi-readable code from an executable file (binary). Using the reversing software Binary Ninja, I will be disassembling executables into assembly code, and modifying and reassembling that code so that it will behave how I want it to.

[z5164445-blog]

Something Awesome:

Part 0: Brave new World

As a preface, I’m starting this project in the hopes that I’ll learn the basics of ‘cracking’ various software; that is to modify the protections of the software that stop me from using either the software in it’s entirety or any access altogether. This process will require me to learn about assembly code and how it differs from higher level code that I’m comfortable with (Ironically, I dropped ‘COMP2121: Microprocessors and Interfacing’ for this course). More specifically, I want to know how the C functions I know and love behave in a lower level environment to the point where I can actually understand the mountains of hexadecimal and 3 letter words that is compiler code.

PS. Fairly sure I just don’t know how to properly install programs on linux but I made Binary Ninja, (the reversing program I will be using)  executable from anywhere in my shell by editing my ~/.bashrc file with the following command.

export PATH=$PATH: /home/Documents/binaryninja

I think that’s a mini something awesome in itself 😉

[z5164445-blog]

Security Everywhere

https://arstechnica.com/tech-policy/2019/06/minnesota-cop-awarded-585000-after-colleagues-snooped-on-her-dmv-data/

Interesting article about abuse of access rights within the Minnesota Police department,

“ When Krekelberg asked for an audit of accesses to her DMV records, as allowed by Minnesota state law, she learned that her information—which would include things like her address, weight, height, and driver’s license pictures—had been viewed nearly 1,000 times since 2003 “

The case is somewhat alarming in the sense that Amy Krekelberg had no reason to believe that her data was being grossly misused by fellow police officers, and that there was no requirements or reasons necessary to view DMV information.

However, it also shows the power that freedom of information allows for.  Not only did the Minnesota police department have records of who accessed her files, Krekelberg was freely able to ask and receive this information, complete with timestamps of when it was accessed. This is despite the fact that the information was able to be used to sue the city of Minneapolis. 

This paints a picture of a government that doesn’t seem to care about the privacy of it’s citizens information, or from a different angle, one that values the freedom of information over privacy.

[z5164445-blog]

Something Awesome: Cracking Applications

When I was a kid, I disliked the idea of paying for things online. However, since I didn’t own a credit card that could make online purchases, I turned to Limewire. I quickly learnt the errors of my ways when our home pc was infected with viruses when I tried to get my games and music for free. Now, I can afford to buy my music and applications, however the idea of reverse engineering and cracking software is still very much interesting to me.

Core Milestones:

Complete Secsoc’s reverse Engineering Challenges from their Workshop (13th June)

Crack a copy of PhotoShop cs6 (A non-subscription version of Photoshop):

·         Application must be cracked from a trial version of photoshop

·         Application must not show any mention of being a trial version

·         Application must be fully functioning upon crack

·         No using cracks made from online sources

o   PS. I have a legit Creative Cloud Account. I promise

 Bonus/Fallback Milestones:

I’m also transitioning from Windows to Linux and am getting into CTF games to accustom myself to the wonders of linux commands. I am aiming to complete the ‘OverTheWire – bandit’ challenges and on extension,’ Leviathon’ and ‘Narnia’,  depending on how quickly I can complete the challenges. Each Level will be accompanied with appropriate blog post on the outcomes and challenges of the exercises.

If Photoshop proves to be beyond my ability I will hopefully be able to fallback onto another commercial software (legally).

HD:

·         Crack Challenges + Photoshop or Similar Commercial App

·         Show comprehensive evidence of how each application was cracked

·          Complete all Bandit exercises/Bonus Exercises in a consistant manner

·         For each bandit exercise, explain what was learnt and what was challenging in weekly blog 

·        Share Weekly blogs that underline comprehensively the successes and              failures of the week  

D:

·         Crack Challenges + Show evidence of attempt at Photoshop/Similar Commercial App Crack

·         Show evidence of how each application was cracked/ Attempted to be cracked

·         Share Weekly blogs that underline successes and failures of week

·         Show progress/attempts at all Bandit exercises/Bonus Exercises in a consistant manner

·         Complete all Bandit exercises/ Attempt Bonus Exercises

C:

·         Show evidence of attempt to Crack Challenges + Photoshop Crack

·         Share Weekly blogs

·         Blog semi-Consistently about each Bandit exercise

·         Complete all Bandit exercises

P:

·         Show sincere attempt at cracking challenges + Photoshop

·         Show at least some evidence of blogs

·         Completed at least two thirds of bandit challenges