I've recently finished reading How to Travel Full Time and Start a Freedom Business by Colin Wright on my Kindle. Throughout especially the former, he lists a number of useful (web) resources for people interested in full time travel. Since browsing the internet kind of sucks on a Kindle, I decided to collect all of these in one place here for others to use more easily.
I've omitted some of the obvious stuff (Facebook, Twitter, Google+, ...). This is a selection of stuff I found particularly useful, didn't know before or tend to forget about.
How To Travel Full Time
http://exilelifestyle.com/ - Colin Wright's website and blog
Travel Blogs
Uncornered Market
Migrationology
Nomadic Matt
Legal Nomads
Castles in the Air
Everything Everywhere
Art of Nonconformity
Almost Fearless
Indie Travel Podcast
Jet Set Citizen
Nerdy Nomad
The Professional Hobo
Vagabondish
Resources
Communication
TinyLetter for creating newsletters
Flickr photo sharing
Picasa photo sharing
Vimeo video platform, a little nicer than YouTube
Evernote task lists, reminders, etc.
Google Docs
Offline Mail Gmail offline plugin
WeTransfer file Transfer
Mailchimp create, design and send emails
To-Do Lists
Wufoo Online form builder
Remember The Milk
Things to-do list for Mac
Toodledoo
Todoist
Moleskine nice leather-bound notebooks, calendars, etc.
Payments/Finance
PayPal online payments (sending/receiving)
Amazon Payments
Google Checkout
Mint personal finance, budgeting, etc.
Passive Panda how to make more money
Man vs. Debt become debt-free
Get Rich Slowly
Freedom Business/Entrepreneurship
Location180 build a business, achieve freedom, live anywhere
Epic Self awaken your mind. freshen your body. referesh your spirit.
The Middle Finger Project to hell with the shoulds; life is short. do what you want.
Nerd Fitness lose weight, get stronger, live better.
Amber Rae lifestyle blog by Amber Rae
The Suitcase Entrepreneur creative ways to run your business from anywhere
The Personal MBA
Remote Working
Nu Nomad work while travelling the world
The 4-Hour Work Week
(if you're in/from Germany: Motius does remote engineering)
Bill Management
Manilla
Mail Forwarding
USA2Me
Malbox Forwarding get mail scanned to read online, rent mailbox, forward mail
USABox
Virtual Post Mail
Earth Class Mail online mail
Zumbox
(Full Time) Travel Gear
Canon Powershot SD1400is
Victorinox E-Motion Trek Pack Plus 20"
WritersBlok notebooks
Kindle
Slim Slimmy Front Pocket Wallet
Timbuk2 Messenger Bag
Gorillapod Tripod
Online Platforms
SquareSpace build a website
Hostgator webhoster
1&1
W3 School HTML Tutorial
Google Code University
Tickets/Flights
Kayak
Hipmunk
Adioso
AirfareWatchdog
SeatGuru find desirable seats
Bing Travel
Cheapoair
Packing
Bundle Method
Rolling Method
Packing Cubes
10 Days in a Carry-On
Travel Safety
General Travel Safety Information
Travel Insurance and Safety Advice
10 Safety Tips for Travellers
Meeting People
CouchSurfing meet people, find place to sleep
OkCupid online dating, but also good for just meeting people in a new place
Travelers for Travelers
Yelp social location/POI/business service
Travel blogging
Everlater (now MapQuest Travel blogs)
TravelPod
World Nomads Travel Blog
File Storage and Backup
Dropbox
Backblaze
Mozy
Carbonite
Monday, August 26, 2013
Wednesday, March 6, 2013
Scroogle is a Mistake
I've just stumbled across this article about Microsoft's Scroogle campaign, and I think it touches on what I wrote about in my last post. The gist of it is this: Microsoft started an anti-Google campaign online, accusing them of invading their users' privacy by going through their e-mail and using that data for targeted advertising.
Microsoft is obviously in the wrong here (and I'd venture to guess that they already know this), they're being hypocritical - what they accuse Google of is something they themselves actively pursue and do research in. From their website:
Why out of all points in time they chose now to attack Google on this issue (Google's been doing this for years) is beyond me, but perhaps they've only now stopped doing it themselves.
But wait! They never have. Microsoft may be advertising Outlook.com with the campaign, but surely they can't just turn around and pretend Hotmail doesn't belong to them - it has nearly the same amount of users as Gmail.
To me, this entire campaign is a misplaced and counterproductive, and I hope Microsoft will eventually come to this conclusion themselves. Microsoft has recently done a great job of recovering their image as an innovative company and has released a range of really great products. I frankly don't understand why they would feel the need to start a negative campaign, instead of focusing on actually being better than the competition.
Microsoft is obviously in the wrong here (and I'd venture to guess that they already know this), they're being hypocritical - what they accuse Google of is something they themselves actively pursue and do research in. From their website:
[...] With broad research efforts in areas like statistical learning, pattern recognition, text mining, optimization, information retrieval, recommendation, we are currently exploring practical technologies to enable large scale knowledge acquisition, to model user intention and to optimize the eco-system which involves users, rich clients and various online services. [...]So, even if they weren't going through your email for advertising, they do actively use your personal data for profit. Of course they do - perhaps Microsoft is less reliant on this than Google, but they need the profits just as much, and they certainly can't afford to not keep up with what other companies do. There might not be anything wrong with this, but frankly it's somewhat embarrassing to see what has been a great company accuse another of screwing their users without reasonable justification.
Why out of all points in time they chose now to attack Google on this issue (Google's been doing this for years) is beyond me, but perhaps they've only now stopped doing it themselves.
But wait! They never have. Microsoft may be advertising Outlook.com with the campaign, but surely they can't just turn around and pretend Hotmail doesn't belong to them - it has nearly the same amount of users as Gmail.
To me, this entire campaign is a misplaced and counterproductive, and I hope Microsoft will eventually come to this conclusion themselves. Microsoft has recently done a great job of recovering their image as an innovative company and has released a range of really great products. I frankly don't understand why they would feel the need to start a negative campaign, instead of focusing on actually being better than the competition.
Saturday, February 25, 2012
Quick- and Mergesort in one line of Python
One-liners are always fun, so as a challenge I decided to implement both Quicksort and Mergesort in one line of Python, one line meaning one expression, no semicolons and no eval(). Quicksort was relatively straightforward, since it only really requires one operation applied recursively:
Mergesort however was more of a challenge. The problem is the merging of two sorted lists - this requires a loop, which is not trivial to implement inside of another recursive function in just one expression. Luckily though, the the process of merging can be achieved through recursion, and so we can pack it into a lambda expression that is called recursively.
We then still have the problem of having a lambda expression call itself inside of another lambda expression - it took some searching, but eventually I found a solution: a Z-combinator.
Looks complicated, but you can see that the first lambda is just the Z combinator, followed by a rather long lambda on the variable m, this is our merge function. The reason for all the or and and's is the they are used to replace (if ... else ...) statements, since we can't nest these arbitrarily in lambdas. Also, the (r.append(a[0]) or a.remove(a[0]) or m(a,b,r)) statements simply return the third element (the recursive function call), since append() and remove() simply return none, and (none or [list] ) returns [list] in Python. This is a neat little hack that can be used to not only combine expressions but also to add return values to functions that otherwise return None.
Note that the Mergesort function here is highly recursive, I could only sort lists of around 330 elements before reaching maximum recursion depth. It is still reasonably fast however, taking around 0.004 seconds to sort 330 elements. Quicksort is much faster though, with 0.0002 seconds for the same list.
Mergesort however was more of a challenge. The problem is the merging of two sorted lists - this requires a loop, which is not trivial to implement inside of another recursive function in just one expression. Luckily though, the the process of merging can be achieved through recursion, and so we can pack it into a lambda expression that is called recursively.
We then still have the problem of having a lambda expression call itself inside of another lambda expression - it took some searching, but eventually I found a solution: a Z-combinator.
(lambda f: (lambda x: f(lambda *args: x(x)(*args)))(lambda x: f(lambda *args: x(x)(*args))))This expression will take as an argument a function that is to be called recursively, and do exactly that. It allows for recursion with anonymous function. So now, all we need to do is pass the merge function to the Z combinator, and then call the resulting expression with the (recursively) mergesorted first and second half of our list. Here'e the code:
Looks complicated, but you can see that the first lambda is just the Z combinator, followed by a rather long lambda on the variable m, this is our merge function. The reason for all the or and and's is the they are used to replace (if ... else ...) statements, since we can't nest these arbitrarily in lambdas. Also, the (r.append(a[0]) or a.remove(a[0]) or m(a,b,r)) statements simply return the third element (the recursive function call), since append() and remove() simply return none, and (none or [list] ) returns [list] in Python. This is a neat little hack that can be used to not only combine expressions but also to add return values to functions that otherwise return None.
Note that the Mergesort function here is highly recursive, I could only sort lists of around 330 elements before reaching maximum recursion depth. It is still reasonably fast however, taking around 0.004 seconds to sort 330 elements. Quicksort is much faster though, with 0.0002 seconds for the same list.
Wednesday, February 22, 2012
pybfc, A BF to C Compiler written in Python
So instead of studying for my exams, I decided to be less than productive and wrote a simple brainfuck to C compiler, in Python. I didn't initially mean for this to come out as hacky as it did, but I eventually decided I wanted to buff it down to 10 lines maximum.
Compiling brainfuck to C is pretty simple really, since all instructions in bf can be seen as operations on a single pointer variable in C, so all that needs to be done is replace each character with the appropriate C statement, which I did through a dictionary. There's a bit of code needed to initialize the program, but from then on it's all just one-to-one replacing. Finally, the script calls gcc to compile the code to be executable, using an optional command line argument as the output filename.
To compile bf code, save this as (for example) pybfc, and then run:
Here's the source for a "Hello World!" program in brainfuck:
Compiling brainfuck to C is pretty simple really, since all instructions in bf can be seen as operations on a single pointer variable in C, so all that needs to be done is replace each character with the appropriate C statement, which I did through a dictionary. There's a bit of code needed to initialize the program, but from then on it's all just one-to-one replacing. Finally, the script calls gcc to compile the code to be executable, using an optional command line argument as the output filename.
To compile bf code, save this as (for example) pybfc, and then run:
./pybfcYou can then execute the generated program just by running ./outputfilename..bf outputfilename
Here's the source for a "Hello World!" program in brainfuck:
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.This compiles to some rather lengthy C code, I won't post it here, but the compiler will actually generate the C code into a file ("out.c") as well.
Tuesday, February 21, 2012
Shellcode, continued
I posted some decoded x86 machine code here last week, however I didn't really explain what it did (also because I didn't actually know yet). I found a cleaned up version of the corresponding Assembler code, complete with comments, which makes the whole thing pretty understandable.
Basically, the code consists of two parts: gaining root privileges, and then spawning a shell. Each is accomplished through a syscall (this is what the int 0x80 instructions are for). I reality, code like this might be deployed through a buffer overflow - for instance, one could flood an unchecked text input field with NOP instructions (0x90), overriding the following memory with instructions to do nothing at all (this is called a NOP slide) , and then placing the shellcode at the end of this slide, causing it to be executed and you to be prompted with a root shell.
Now, it's not quite as simple as that, after all the string (and shellcode) will only be copied into the buffer, and even if it overflows it, the code's execution is not guaranteed. For this, some function will have to actually have to jump or return to an address that lies somewhere on our NOP slide. If you want to find out in detail how to do this, I suggest you read this very excellent article on the subject.
Basically, the code consists of two parts: gaining root privileges, and then spawning a shell. Each is accomplished through a syscall (this is what the int 0x80 instructions are for). I reality, code like this might be deployed through a buffer overflow - for instance, one could flood an unchecked text input field with NOP instructions (0x90), overriding the following memory with instructions to do nothing at all (this is called a NOP slide) , and then placing the shellcode at the end of this slide, causing it to be executed and you to be prompted with a root shell.
Now, it's not quite as simple as that, after all the string (and shellcode) will only be copied into the buffer, and even if it overflows it, the code's execution is not guaranteed. For this, some function will have to actually have to jump or return to an address that lies somewhere on our NOP slide. If you want to find out in detail how to do this, I suggest you read this very excellent article on the subject.
Thursday, February 9, 2012
Balancing Graphs in O(n*log(n))
The Barnes-Hut algorithm is used to model N-body systems more efficiently, at the expense of precision. However, the improvement in performance is tremendous: from O( n² ) to O( n*log(n) ). For reference, this is what that looks like:
Since our force-based approach to computing graph layout is essentially nothing other than an N-body simulation, and we don't require great precision anyway, this algorithm seems perfect for us to use. The way it works is basically this:
- The set of nodes is sorted into a quadtree, which is essentially a binary tree, but with an added dimension
- Each of the quadtree sectors keeps track of its mass and center of mass
- To compute the forces, the tree is traversed and for points that are "far" from a certain center of mass, only the force from the node to that center of mass is calculated, as opposed to each force between all nodes
This leads to a significant decrease in overall calculations that needs to be done, since distant nodes no longer need to interact directly. There is some overhead on creating the quadtree every frame, but the growth of this is also O(n*log(n)). If you want to learn more, here is a very good explanation of the algorithm complete with pseudocode (in German, but the code is understandable anyway).
I haven't had time to implement this algorithm in our Qt application to graph Wikipedia, however I managed to code up the basic algorithm in Python. The improvement is tremendous, before I was never able to reasonably run a simulation with more than 80 or so nodes in Python, now even systems up to 350 nodes run at a reasonable framerate.
 |
| Illustration of the quadtree (unbalanced) |
 |
| The same graph after balancing |
The algorithm can also be parallelized very well, so the potential of this is tremendous, with good implementation and appropriate hardware we could realistically graph all of the German Wikipedia (~1.3 million articles), maybe more.
The full Python code is here.
Sunday, February 5, 2012
De-coding Shellcode
Disclaimer: I don't know if I did any of this correctly, do not rely on this. Just writing about my own learning process.
As part of one of my courses at university, I've been learning a bit of x86 Assembly lately, as well as how actual machine code corresponds to it. I wanted to try and apply this to some "real" code, and since I'm currently half-working on Jon Erickson's "Hacking - The Art of Exploitation", I decided to try and convert a piece of shellcode back to its mnemonic asm form. I really wanted to do this also because I want to know what exactly the shellcode does, as this wasn't explained (at this point in the book, anyway).
Let's take the first instruction for instance: 0x31. This reveals that 31 represents the XOR r/m16/32, r16/32 instruction. Here I ran into the problem of not knowing what registers were being operated on. Googling was difficult, since I didn't even know what question I was really asking, but luckily I got some help in my freshman class Facebook group, and was pointed to this page. As it turns out, the registers are specified by the next command: xC0.
How does identifying the registers work? Each register has a sort of id to reference it, and here the xC0 contains the applicable ids. Below all ids are listed:
We also work with constant values sometimes, we call them immediates. The above shellcode contains a few instances of this, the first starting at \0xb0, which is the MOV r8, imm8 operation. Again, the register (8 bits only this time) is encoded by its id, but this time in the opcode directly, like this: b0 to b7 each represent the same operation, and the second 4 bits represent the register to use. Here, this is register 0, which our table above says is eax, but since we#re working with 8 bit registers, it's gonna be al. The next byte, 0xA4 is the immediate, making this whole operation: MOV $0xA4, %AL.
Then there was a tricky part which I'm not 100% sure I got right, at least I can't see what exactly it does. It starts at 0x68, which specifies the operation PUSH imm16/32. What confused me was whether only the next 2 or the next 4 codes would belong to this operation. I was suspecting 4 (making it 32 bit), since pushing registers such as eax would also be 32bit, but I wasn't entirely sure. Anyway, I then found this in a disassembly of some C program:
So it seemed that all four codes belonged to this instruction:
As part of one of my courses at university, I've been learning a bit of x86 Assembly lately, as well as how actual machine code corresponds to it. I wanted to try and apply this to some "real" code, and since I'm currently half-working on Jon Erickson's "Hacking - The Art of Exploitation", I decided to try and convert a piece of shellcode back to its mnemonic asm form. I really wanted to do this also because I want to know what exactly the shellcode does, as this wasn't explained (at this point in the book, anyway).
Here's the raw shellcode:
\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x6a\x0b\x58\x51\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x51\x89\xe2\x53\x89\xe1\xcd\x80Looks like nothing much to me. Anyway, I found a pretty decent resource for looking up the corresponding mnemonics for opcodes, however putting it all together was still at times tricky for me.
Let's take the first instruction for instance: 0x31. This reveals that 31 represents the XOR r/m16/32, r16/32 instruction. Here I ran into the problem of not knowing what registers were being operated on. Googling was difficult, since I didn't even know what question I was really asking, but luckily I got some help in my freshman class Facebook group, and was pointed to this page. As it turns out, the registers are specified by the next command: xC0.
How does identifying the registers work? Each register has a sort of id to reference it, and here the xC0 contains the applicable ids. Below all ids are listed:
eax = 0 = 000The next operand (here xC0) is organized such that the bits 3-5 represent the source and bits 0-2 represent the operation's destination. In binary, xC0 = 1100 0000, so using our table above, we see that both operands are in fact register eax, making the first operation XOR %EAX, %EAX, which as far as I can see just clears the register. Similarly, the next two operations clear registers ebx and ecx.
ecx = 1 = 001
edx = 2 = 010
ebx = 3 = 011
esp = 4 = 100
ebp = 5 = 101
esi = 6 = 110
edi = 7 = 111
We also work with constant values sometimes, we call them immediates. The above shellcode contains a few instances of this, the first starting at \0xb0, which is the MOV r8, imm8 operation. Again, the register (8 bits only this time) is encoded by its id, but this time in the opcode directly, like this: b0 to b7 each represent the same operation, and the second 4 bits represent the register to use. Here, this is register 0, which our table above says is eax, but since we#re working with 8 bit registers, it's gonna be al. The next byte, 0xA4 is the immediate, making this whole operation: MOV $0xA4, %AL.
Then there was a tricky part which I'm not 100% sure I got right, at least I can't see what exactly it does. It starts at 0x68, which specifies the operation PUSH imm16/32. What confused me was whether only the next 2 or the next 4 codes would belong to this operation. I was suspecting 4 (making it 32 bit), since pushing registers such as eax would also be 32bit, but I wasn't entirely sure. Anyway, I then found this in a disassembly of some C program:
PUSH $0x68732f2fBelow is the full shellcode, decoded. I'm still not sure how it works exactly, in the book it is used in a buffer overflow to spawn a shell.
Subscribe to:
Posts (Atom)