dylanedwards.com | Dylan Edwards

I wrote a little app to toggle the hiding/showing of hidden files in the OS X Finder, and I’m going to tell you about it. You can find it here (download link) or on my Projects page. The largest part of this application is the icon. The executable file itself is actually just a shell script, the entire source of which is as follows:


#!/bin/sh

if [ `defaults read com.apple.finder AppleShowAllFiles` = "false" ]; then
defaults write com.apple.finder AppleShowAllFiles true
else
defaults write com.apple.finder AppleShowAllFiles false
fi

osascript -e 'tell application "Finder" to quit'

# Finder often tries to open too quickly (causing weird problems)
# so I tell it to wait a second.
sleep 1

osascript -e 'tell application "Finder" to activate'

After seeing that, you might wonder how I got a stupid little shell script all packaged up so nicely in a .app. I’m running low on ideas to blog about, so I guess I’ll explain!

Basically, every OS X application bundle is really just a bunch of files thrown into a folder. The application you see is just a directory with “.app” appended to the end. To view the contents of an app, simply select it in Finder, click the gear in the toolbar, and select “Show Package Contents”. The two things needed to make an application run are the executable (which resides at MyAppName/Contents/MacOS/executablegoeshere) and an Info.plist file. The executable is the code that runs and the Info.plist just tells the OS what everything in the bundle is. If you open up the plist, you’ll see it’s basically an XML document telling the OS what my executable is called, what the icon is called, and giving my app a unique identifier (com.dylanedwards.houdinifile).

, , , Hide

I started Project Euler over the Summer and totally forgot about it. The other day I started playing around with ideas of writing a library for integer math with arbitrarily-large numbers in C. As I started writing code, I remember a Project Euler problem (number 13) involving the sum of 100 50-digit numbers that I wanted to solve, so I got some basic arithmetic operations coded and solved it (woohoo, source is now on my Project Euler page).

Anyway, the point of this post is that I wanted to share the code with you. It’s now available here (download link) (moved to http://big-integers.googlecode.com) or on my Projects page. It’s very basic and doesn’t currently support division, comparison, or negative numbers. All of those things (and more!) are coming soon, but I just thought I’d post what I have done. I’ll probably keep updating it (and I’ll post to let you know) over the next week or so.

The algorithms for the three operations that it supports (addition, subtraction, multiplication) are all built off of the basic concepts that we all learned in elementary school. They’re all very simple (the multiplication looks a little confusing at first), and work exactly as if you were solving a problem on paper.

Enjoy!

PS. You can adjust the size (number of digits) of the bignum type in bn.h.

, , , , Hide

Almost everyone is familiar with the concept of wireless networks and how insecure they can be. Everyone has heard some story about how all your data can be stolen while you surf the web at Starbucks, and hardly anybody does anything about it. I think most people are under the impression that there’s no way stealing information can possibly be that easy, so no one is doing it. The truth is that stealing information is incredibly easy, and some of us are doing it all the time!

The information contained in this article is for educational purposes only. Using it incorrectly can get you in a lot of trouble (if you don’t believe me, I’ll tell you my United States Secret Service story sometime!), so be responsible.

Today we are going to be using a packet sniffer. A packet sniffer basically just listens on a network interface and intercepts all of the packets it sees. If you want a more in-depth explanation, read Wikipedia. Our packet sniffer of choice today will be Wireshark. There’s the download link.

Wireshark is available for all the common platforms, but there are a few problems with getting it running on a Mac. In Mac OS X, ordinary users do not have access to the capture devices needed to capture traffic. There are a few remedies to this, and they are as follows:

  1. Log in as root – First make sure that the login window is set to display as Name and Password (System Preferences->Users->Login Options) and then log out (Shift+Cmd+Q). Log in with the name System Administrator and whatever password you have set for root. Now run the program.
  2. Run the program with sudo – From the terminal, navigate to the Wireshark binary (usually /Applications/Wireshark.app/Contents/MacOS/) and run it with the command ‘sudo ./Wireshark
  3. Change the permissions on your capture devices – From the terminal, run the command ‘sudo chmod a+rwx /dev/bpf*‘ (for the curious, this gives everyone read/write/execute privileges for those files) and then run the program.

After doing one of those, you are ready to steal people’s precious data. Once Wireshark is launched, click on the menubar on [Capture->Interfaces...]. The window it presents will list the interfaces you can listen on. Find the one you want to use (probably your WiFi card which is usually en1) and hit start. You are now monitoring all network traffic on that interface. You can analyze the data as it comes in, or you can leave your computer locked inside an old van in the parking lot on a hot summer day until you have all of the information that you could ever need.

Now that you’ve got some data, let’s look at what you can do with it. Most importantly, we can save it for later. Try out [File->Save As...] to save your PCAP dump (that’s what they’re called) for later use. As far as analyzing the data, let’s start by talking about what you see in Wireshark. Looking at a PCAP dump, you see 6 columns across the top labeled: No., Time, Source, Destination, Protocol, and Info. One at a time.

  • “No.” is pretty simple, it’s the packet number. Every packet you collect is incrementally numbered.
  • “Time” is pretty straightforward, too. It’s the number of seconds elapsed since the capture began at the time the packet you are looking at was captured
  • “Source” is the source (where the packet originated from) IP address. If you don’t know what an IP address is, you might be reading the wrong blog.
  • “Destination” is the destination (where the packet was headed) IP address.
  • “Protocol” tells you what protocol the packet in question used. Was it an FTP packet? HTTP? ARP? DNS? Find out here!
  • “Info” is exactly what it sounds like. It’s a bit of information about a packet.

When you click on a packet, the bottom part of you Wireshark window should change to display the data contained in that packet. Usually this is just gibberish that means nothing out of context. To give it some context, you would need to see all of the packets in the stream- fortunately Wireshark makes it really easy to do that. If you right click on any packet in the list and select Follow TCP Stream, Wireshark will do just that: filter out all the packets in that TCP stream and present them in a continuous, readable format.

Now let’s do something interesting. Most people are aware that FTP information is sent in plaintext. Those that don’t know this should. No one should ever use plain FTP (use FTPS or SFTP instead). I am about to demonstrate why- feel free to follow along! I’ll start by firing up Wireshark and monitoring packets on en1. Once that’s going, I’m going to initiate an FTP connection. For the purpose of demonstration, you can do this from Finder (Mac OS X) with Cmd+K and the address of the ftp server (if you don’t have a server, enable FTP on your local machine). Once you’ve connected (with username and password), tab back over to Wireshark and stop your capture. Now that we’ve got some data, we can dive in a bit deeper.

Most malicious uses of Wireshark simply involve knowing what you’re looking for. In this case, we are fishing for FTP passwords, so let’s sort our packets by protocol and scroll till we find FTP (advanced users might just filter their packets with the filter ‘ftp’). You should be able to pick just about any packet near the top and follow its TCP stream to find what we’re looking for. Here’s what I found:


USER dylan
220---------- Welcome to Pure-FTPd [TLS] ----------
220-You are user number 3 of 50 allowed.
220-Local time is now 20:44. Server port: 21.
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 15 minutes of inactivity.
331 User dylan OK. Password required
PASS asdfMyPassw0rdasdf
230-User dylan has group access to: dylan
230 OK. Current restricted directory is /
SYST
215 UNIX Type: L8
PWD
257 "/" is your current location
TYPE I
200 TYPE is now 8-bit binary
CWD /
250 OK. Current directory is /
PASV
227 Entering Passive Mode (67,43,13,30,139,195)
LIST

As you can see, my password (obviously I changed it for the example) is right there in plaintext. If I was on a public WiFi network, anyone with a packet sniffer could now connect to the IP given in the destination column using the username and password they found.

This post has become way longer than I expected, so I must wrap it up now. In short, Wireshark can collect all sorts of useful information. Web sites, email, instant messages, FTP, and many, many more common applications all send data in plaintext. A quick Ctrl+F over all of your packets for words like “Pass” can often reveal some pretty fun stuff. I hope this tutorial explained at least enough to get you in a bit of trouble, and as always, I welcome any and all feedback/questions!

Oh, and maybe you could even comment?

, , , , , Hide

Nov/09

21

Open-RP Update

I’m still waiting on a friend to loan me his hacked PSP before I can continue any further with my Open-RP endeavor. In the meantime, there is more content on the way! I wrote an article tonight on packet sniffing; I will post it tomorrow after I’ve had a chance to proofread it at a time other than 1 AM.

, , , Hide

I just discovered that there’s a bounty out for porting Open Remote Play to the iPhone. It’s been a long time since I’ve done any fun, notable hacks, and I think I might give this a shot (if I can find the free time for it).

Check out the posting on dashhacks.com.

, , , , Hide

Now it’s time for some poorly-written, lengthy sentences. I’m going to go ahead and explain a basic overview of how most simple apps are cracked on OS X. You most likely won’t walk away with knowledge of how to crack applications yourself, but if you’ve understood everything so far, you can probably teach yourself. Before I go any further, I would like to firmly state that this information is for educational purposes only and should not be redistributed or used to do anything illegal/unethical. I enjoy cracking applications because it gives me a better understand of what my computer is really doing, and I hope to share the joy of understanding with you. I do not condone piracy. If I like software, I buy it (and so should you). Now time for the good stuff.

The start of nearly every Mac OS X crack begins by examining the code contained within an application. You probably don’t have access to the source code of the application you are looking to crack, so you have to yank that information out of the app itself. This is both possible and easy thanks to our friend otool. With the right arguments, otool will dump out the code contained in an app. Gathering the correct arguments and digging through code to match up Objective-C method names can be a pain even after you’ve used otool, and that’s why otx is a lifesaver. otx is a GUI app that makes life easy by dumping a prettified otool output and more into a text file.

Running otx on an application’s executable (located at MyAppName.app/Contents/MacOS/MyAppName) for x86 will yield a beautiful mess of output that looks a bit like this (from Apple’s Calculator):

-(void)[LCDController setPrecision:]
+0 00003595 55 pushl %ebp
+1 00003596 89e5 movl %esp,%ebp
+3 00003598 8b4508 movl 0x08(%ebp),%eax
+6 0000359b 8b5510 movl 0x10(%ebp),%edx
+9 0000359e 895058 movl %edx,0x58(%eax) (int)__Precision
+12 000035a1 8b1578550100 movl 0x00015578,%edx showValue
+18 000035a7 89550c movl %edx,0x0c(%ebp)
+21 000035aa 894508 movl %eax,0x08(%ebp)
+24 000035ad c9 leave
+25 000035ae e9cbc80000 jmpl 0x0000fe7e

So you’re probably wondering what all of that means, right? I’ll go ahead and explain it a bit. The first line (with the brackets around it) is a method name. The fact that we can read these is important because it often gives clues as to what the app is doing when it calls that method- for instance, in this case the App (calculator) is setting its precision.

The first column you see is a local offset, or the offset within that method. It basically gives you an idea of how far into a particular method you are. The next column is the actual offset of the code- this is important to note because it is where the code you are viewing resides within the executable file. If you wanted to patch a piece of code, you could skip right to its offset in the binary. The next column is the opcode for the current instruction. This is the part that tells the computer what to do, and it’s the part you generally end up modifying in an executable. The last few columns are the assembly language instructions for what is going on.

Now that you have a clearer idea of what you are looking at, I’ll talk about the most simple reverse engineering technique. When you are trying to crack an application, you are generally looking to circumvent some sort of registration or trial restriction on the program. Most of the time, this means finding the location of the relevant code and patching the binary to ignore it. To find the necessary code, you can search through the otx dump for key words like “Register”, “Nag”, “Trial”, “Expire”, and more. You have to use your brain and take a look at what the methods are named and where they are being called. Try to get an understanding of what the program is doing and when. Most hackers use a debugger like GDB to actually follow the flow of the program, but this is a vast over-simplification based on guesswork.

The majority of the time, a crack comes down to modifying one single line of code, and that is the conditional check for a registration (where the program is checking whether or not you have a registered copy). In Objective-C, these checks tend to follow a pattern. Below is a snippet from an otx dump that is key to a crack:

+2351 00004481 e8f8b90000 calll 0x0000fe7e -[(%esp,1) isRegistered:]
+2356 00004486 84c0 testb %al,%al
+2358 00004488 752f jne 0x000044b9

What’s going on here (skipping a lot of essential code that comes before an simplifying what’s going on) is pretty easy to understand! The program is calling (see calll?) the method isRegistered: and is then testing (see testb?) the result. What usually follows is one of two instructions: jel or in this case, jne.

What do these instructions mean? Easy. jel means “jump if equal” and jne means “jump if not equal”. Jump just means to skip to a different part of the code. In this case, if you are not registered, it is going to skip to the part of the code that kicks you out. So 99% of cracks come down to reversing or ignoring one of these instructions.

In the pasted code, the program is checking if it is registered, testing the result, and jumping if the result is not equal (if this sounds funny go learn assembly or just accept that it’s not extremely important). Since the program is going to continue jumping to kick us out as long as we’re not registered, we want to remove or ignore the jne instruction and let the program continue on as if we were in fact registered.

If you’ve read my earlier posts, you probably know where I am going, and that is to nop. nop (opcode 90) is the “do nothing” instruction in assembly language. All we want to do is replace our little jne with a nop. To do this, you simply open the app’s original executable in a hex editor, jump to the offset from the otx dump ( 0x4488 in this case) and replace the offending code (752f) with nops (9090).

Voila, our imaginary app is cracked. Sorry for the horrible writing, I’m doing this at 1:22 AM instead of stressing over homework. This probably wasn’t the most clear guide, and it certainly isn’t the most accurate (like I mentioned, almost every real cracking process involves using GDB). If you have any questions or would like my help, feel free to comment or shoot me an email.

There will be another informative (and easier to understand) post coming soon on packet sniffing in Mac OS X!

, , , Hide

I’d like to take the opportunity to explain some things to those of you who actually go outdoors on a somewhat regular basis. A lot of the posts that you will see on this site may confuse you, and I would like to prevent that. I’d like to do a couple things: first I’ll write out a glossary of terms you will encounter frequently, and second (when I’m more awake) I will write a description of a basic reverse engineering process. The second part will be in another post. The first part will happen RIGHT NOW.

I’ll start off with a couple broad terms:
Hacking – making things do stuff that they weren’t originally intended to do (I’d really like to hear others’ opinions on this).
Reverse Engineering – in the context I use it, reverse engineering (or RE) is the process of taking apart and analyzing software. Sometimes this means prodding around to see how things work, sometimes it’s just a step toward a bigger goal.

And now some more technical stuff:
Assembly [Language] – Assembly language is often considered the lowest-level human-readable programming language. It’s still not very human-readable. It’s mostly hard-to-understand instructions telling the computer hardware/OS exactly what to do.
Hex Editor – A program used to alter the contents of binary files such as compiled programs.
Method – In Objective-C (the predominate language of Mac OS X), a method is (in basic terms) a specific, named task that a program performs. otool dumps method names next to the low-level code when possible, making it easy to find relevant pieces of code.
Offset – A hexadecimal number that refers to a specific location in a binary file. Almost (but not quite) like a line number for geeks.
Opcode – A little hard to explain. Assembly language can be written out in opcodes, which is what the instructions in compiled programs are made of.
otool – A utility built in to Mac OS X that displays the low-level (hard to understand) code contained in a program in a pretty format.

These are some basic terms. I’d appreciate any feedback/questions on what I’ve written or what I should have written. This list might grow and I might make it into its own page. Until later (probably tomorrow), look forward to BUT WHAT DOES IT ALL MEAN? (pt. 2).

, Hide

Nov/09

5

Building a New PC

I’m slowly, part-by-part building myself a new gaming rig. Currently I’ve got a strange mesh of nice parts in a crappy old computer, but hopefully I will have something nice built by the end of the year. In my old Dell Dimension 4700 (3.2 GHZ Pentium 4) I currently have a brand-spankin’-new Radeon 4890 graphics card and an Antec Earthwatts 650W PSU.

It’s hilarious playing games on this computer- I can play a lot of games (Source engine and more) at maxed out settings with silky-smooth frame rates, but as soon as I have to load a level or save or ANYTHING that depends on CPU/HDD/any other component, I better prepare for a 10 minute wait. I’m looking to take advantage of Intel’s RetailEdge deal this winter to eventually build a sweet Core i7 rig, but we’ll see how that works out.

, , Hide

Oct/09

26

Zapping AppZapper

Another fun “crack” working on the latest version (1.8.0). This one works by giving you an infinite number of “trial” zaps.

I ran through the usual process of dumping the binary with otool and grepping for interesting lines. I ended up finding a couple interesting methods, the first of which is titled -(void)[AZPreferencesController showNag:]. Within that method is a call to -(BOOL)[AZRegistrationController validateExistingRegistrationInformation]. nop’ing out that call prevented the registration nag dialog from showing when launching, but did not allow any extra functionality- I left it in anyway. To do this, open up the AppZapper excutable in your favorite hex editor and skip to offset 0x3bb1b. All you have to do is replace the opcodes for the method call (e883450100) with nops (9090909090). A nop (opcode 90) basically just means “do nothing” in assembly.

The next interesting method I came across was titled -(void)[AZAppController _finishProcessingApps:]. Sounds boring- I know- but it contains an important call to the method -(BOOL)[AZRegistrationController canZap]. This is the method that determines whether or not the application is allowed to zap. All I had to do was nop out the jel immediately after this call, and the app would allow me to zap indefinitely beyond “0 trial zaps remaining” (I think I’m at -17 now). All you have to do is nop out 0f848d010000 with the good ol’ 909090909090 at offset 0x35527.

NOTE: This only works on x86-32. If you aren’t running an Intel chip, buy a new computer already.

, , , Hide

Oct/09

25

Expanding ExpanDrive

The “crack” here is pretty simple and appears to still work on the latest version of the app (2.0.6), though the offset has changed throughout the versions. After dumping the app with otool and grepping my way through the file, I stumbled upon quite a few interesting methods. The most important of which is +(BOOL)[LicenseController isTrial]. Within this method is a je instruction at offset 0x114ab. Changing this je (jump if equal) to a jne (jump if not equal) tricks the app into doing the opposite of what it should in detecting whether or not we are running a trial. If you have a valid license (I now do), it will kick you out; if you do not have a valid license, you can enjoy your “registered” copy! All that you need to do is fire up your favorite hex editor and change 0x114ab from 74 (opcode for je) to 75 (jne).

NOTE: This only works on x86-32. If you aren’t running an Intel chip, buy a new computer already.

, , , Hide

Older posts >>

Find it!

Theme Design by devolux.org