Well I finally decided to make this public – I wanted to improve it a bit but I don’t think I’ll get down to doing so. I’m moving away technical content to Github. I’ve long wanted to play with Twitter Bootstrap and this is probably the easiest way. From now on, I’ll mostly update this blog occasionally. Please do follow my new blog – it needs a lot of love :D. Also, do let me know your suggestions! The blog is in a nascent stage and am sure it could use a lot more enhancements!
Recently I saw a presentation by Brendon Rapp titled “Why Z shell(zsh) is cooler than your shell” and I must say I was intrigued by zsh. I took it for a test drive and never turned back from it. zsh has been a great discovery and is my default shell now. While I’m no expert in zsh, I’d like to share what I found pretty cool about zsh.
From April 20th to July 20th 2013, Wise Earth Technology (many friends of mine are a part of this) is hosting an international programming challenge to build an open source body of code; the software base for the Crisis Communicator.
The three month challenge involves coding a browser-based UI, and a database back-end, with GIS features. A grand prize of €1000 goes to the entry that best fulfils the challenge requirements.
Additional sub-challenges carry additional prizes! Follow the hashtag: #CrisisCommunicator
What is the CrisisCommunicator?
The CrisisCommunicator is a device that solves some of the problems faced by disaster responders and response coordinators. Normal communication systems often fail or are unreliable in disasters and crises, forcing responders to rely upon voice communication, simple radio messaging protocols, and expensive solutions like satellite communication.
By building on today’s solutions, a network of CrisisCommunicators create a Disaster Management Communication Information System (the focus of this challenge), exchanging data messages via APRS, and providing a robust hardware device to access it’s features. Every CrisisCommunicator operator will have access to information coming from all around the disaster area, in a distributed
system with multiple redundancy.
Who can take the Challenge?
This Challenge is open to everyone from grizzled programmers to pythonistas to college students! You o not need a radio license to develop the software.
HAM radio operators are invited to help with development, testing, feature planning, and implementation. Web programmers, python hackers, and others are needed to build an intuitive, fast-to use, extensible, and lightweight interface.
What is the challenge goal?
The end product of this challenge will be an open source body of code; the software base for the CrisisCommunicator. Through this challenge, we also want to jump-start an online community of developers interested in seeing this go forward.
The challenge involves coding a browser-based UI, and a database back-end, with GIS features. We prefer Python, for many reasons, but if you want to use another widely used language, we are open to it!
Will it always be open source?
YES! Wise Earth Technology is based on and committed to Open Source. By building the CrisisCommunicator in the Open Source domain, any individual will be able to build their own device with a computer and a radio. This ensures that the CrisisCommunicator functionality will be available to all, immediately upon development! Code will be licensed under the new Peaceful Open Source License (PeaceOSL).
How do I join the Challenge?
It’s easy! Come to our website and start coding! http://wiseearthtechnology.com/
Wise Earth Technology is based on and committed to Open Source. By building the CrisisCommunicator in the Open Source domain, any individual will be able to build their own device with a computer and a radio. This ensures that the CrisisCommunicator functionality will be available to all, immediately upon development! Code will be licensed under the new Peaceful Open Source
I have started with the course “Introductory Intel x86: Architecture, Assembly, Applications, & Alliteration” by Xeno Kovah and it’s been wonderful so far. It is a repeat of many things I am already aware of but there has been a lot of new things learnt. I might write about parts of what I learnt from the course but not everything. This post is about x86 register, conventions associated with them as well as function call conventions.
There are 9 registers in x86: EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP and EIP. These are mostly derived by prefixing E(Extended) to their 16 bit equivalents.
EAX: The accumulator. This register typically stores return values from functions.
EBX: This register is typically the pointer to the base of an array.
ECX: This is typically used as a counter: loops, iterating through an array etc.
EDX: Commonly used as a supporting register. For example, 64 bit return values are returned in EDX:EAX in the code generated by 32 bit compilers.
ESI: The source index for string operations.
EDI: The destination index for string operations.
EBP: This register points to the base of the current function’s stack frame.
ESP: This register points to the top of the current function’s stack frame.
EIP: This register points to the address of the next instruction. This is the only instruction that cannot be manipulated by any instruction except call and ret.
x86 register conventions
Caller save registers: These registers have to be saved by the caller function if it wants to preserve their values. EAX, ECX and EDX are caller save registers. EAX is usually modified by the callee in almost all cases(it holds the return value remember?)
Callee save register: These registers have to be saved by callee function if it will modify these registers. EBP, EBX, EDI and ESI are callee save registers. EBP is usually modified by the callee in almost all cases(it points to the base of the function’s stack frame remember?)
There are multiple ways to pass the parameters to the callee function. Here I will discuss 3 such conventions.
1. CDECL convention: C Declaration. In this convention, the parameters are passed in the reverse order(i.e. from right to left) on the stack by the caller and the caller is responsible for cleaning up the parameters from the stack i.e. it is caller clean up. GCC follows this convention. I think even MS Visual Studio does-at least the free Express edition.
2. STDCALL convention: Standard Call. This is exactly same as CDECL except that the callee is responsible for removing the parameters from the stack i.e. it is callee clean up. The Win32 API follows this convention.
3. FASTCALL convention: I have never encountered this convention before but the idea is that some parameters are passed through the registers and rest through the stack. There is no universal standard-each compiler designer has a different implementation of the convention. This is also callee clean up.
Well that’s about it for this post. I’ll probably write more about x86 programming later on.
National Level “Capture the Flag” style ethical hacking contest
Not a day passes when several machines are compromised and infections spread rampantly in the world today. The cyber world has witnessed several dangerous attacks including the Stuxnet virus and it’s successor Duqu. Other recent attacks include the Flame malware, which managed to disguise itself as a legitimate Windows software. It exploited a bug in Windows to obtain a certificate which allowed itself to authenticate itself as genuine Windows software. Other notable examples include rise of botnets such as the highly resilient Zeus banking trojan and the Conficker worm. There have also been instances of espionage by government agencies on one another such as the recent incident where Georgia CERT discovered a Russian hacker spying on them.
Indian websites offer little or no resistance to such security incidents. The Computer Emergency Response Team, India(Cert-In) has been tracking defacements of Indian websites amongst other security incidents. Their monthly and annual bulletins detail the various vulnerabilities and malware infections in various Indian websites. It’s really sad that with so much talent and skill, Indian websites are compromised frequently and nothing can be done to stand this wave of attacks on them.
InCTF is a Capture the Flag style ethical hacking contest, a strategic war-game designed to mimic the real world security challenges. Software developers in India have little exposure to secure coding practices and the effects of not adopting such practices-one of the main reasons why systems are compromised quite easily these. Following such simple practices can help prevent such incidents.
InCTF ‘13 is from December 2012 to April 2013 and is focused exclusively on the student community. You can participate from your own university and no travel is required. No prior exposure or experience in cyber security needed to participate.
What you need to do?
1. Form a team (minimum three and maximum five members from your college)
2. Approach a faculty/mentor and request him/her to mentor your team
3. Register online at http://portal.inctf.in
|20K||The winning team receives a cash prize of up to Rs. 20000/-|
|15K||The first runner-up team receives a cash prize of up to Rs. 15000/-|
|10K||The second runner-up team receives a cash prize of up to Rs. 10000/-|
- Teams are awarded prizes based on their performance
- Deserving teams are well awarded. Exciting prizes to be won.
So, what are you waiting for? It’s simple: Register, Learn, Hack!
Keep up with us
*Cash prizes are subject to their performance and participation in the CTF round. Only teams who connect to the VPN server and successfully gain points in the CTF round are eligible for prizes. In addition, cash prize winners of previous editions of InCTF and sCTF are not eligible for prizes this time. Prizes will be awarded only if all members of the team are not in final year of their education. The decision of Team InCTF is final.