Ever since I got my first Verizon Blackberry I have been pissed off that Verizon ships the device, that I paid my hard earned money for, in a crippled fashion. Verizon chose to ship the device with the GPS disabled so that you can't use it without paying them 10$ a month. It could have been 1$ a month and I would have been angry about it, but 10$ a month to use a piece of GPS hardware that doesn't even use their network is just ludicrous.
Well, I've been doing quite a bit of research into mobile devices recently (for other reasons not listed) and came across some documentation that demonstrates exactly how to enable the GPS for free. I've copied it here for posterity; this is not my research, but it's certainly cool enough that I'll post it here to every Verizon phone user to read.
1. Enter your device's engineering screen. On the Storm press and hold the back arrow hard key and press the top left, top right, top left, top right of the touch screen. Then enter the code generated from http://absolous.no-ip.com/projects/escreen/. Other models may differ.
2. Choose Radio Engineering Screens (Multi) -> GPS -> GPS Options -> Operation Mode and set the value to "Standalone".
3. Save by pressing menu and choosing save.
4. Enjoy your now working free GPS and make sure to send Verizon the middle finger.
Addendum:
Python escreen generation code:#!/usr/bin/env python
import hmac
import hashlib
pin = 'ffaa0000' # Device PIN [XXXXXXXX]
app = '4.6.0.100 (233)' # OS Application version [n.n.n.n (n)]
uptime = '12345' # Uptime in seconds
duration = 30 # Duration for key to last [1, 3, 6, 15, or 30]
lifetime = {
1: "",
3: "Hello my baby, hello my honey, hello my rag time gal",
7: "He was a boy, and she was a girl, can I make it any more obvious?",
15: "So am I, still waiting, for this world to stop hating?",
30: "I love myself today, not like yesterday. I'm cool, I'm calm, I'm gonna be okay"
}
secret = 'Up the time stream without a TARDIS'
data = pin + app + uptime + lifetime[duration]
hash = hmac.new(secret, data, digestmod = hashlib.sha1)
key = hash.hexdigest()[:8]
print key
Reference:
http://feisley.com/2009/09/26/blackberry-escreen-keygen/Wrote a new blog post for my work blog at Veracode - Zero In A Bit. A short interesting take on yet another reason why application security is the last line of defense. Go check it out!
Phrack issue #66 has been released today. Available at http://www.phrack.org
I absolutely loved this post by a colleague at "the anti-shazzzam" blog. She has some excellent incites and wrote a fantastic piece on the unwritten laws of the security researcher. These laws can be expanded to encompass just about any research related field, but has specific twists and caveats to the nerd side of security research. I highly recommend that anyone doing security research read and digest these unwritten rules on how to make your (and everyone's) life quite a bit easier.
The entire article is HERE. The rules in their entirety are pasted below for posterity. Please go to her blog for comments and additional interesting reading!
1. Do not release 0day that was accidentally pasted into a SILC/IRC channel. Quick edit is evil, and a few of us (*cough*) have had the right mouse button get away from us and accidentally paste a day.s work into a channel. We squeek and hope that people in that channel decide to keep it to themselves. We signed that NDA, we do not want a lawsuit.
2. Do not steal research. If someone said something that sparks your own research tangent, indulge like a horse at a salt lick. But if someone casually drops a reference to their current research idea or project, do not feverishly research and release it before they do.
3. The page-up button is our friend. Scroll-back exists. Chat is logged. Do not expect people to welcome you back with open arms if you exhibit poor behavior. Don.t be a dick.
4. Research ideas are the bread and butter of potential future revenue and recognition. Keep research to yourself until it is mostly infallible and is developed enough to be digested by the public. If the research is not tangible enough, expect that it will be further developed by someone else, or ripped apart by opposing research. Joanna Rutkowska is a prime example of how not to promote your research. People probably would not have wanted to shred her so badly if she had presented herself a little bit differently.
5. Do not talk about other.s research before they do. Chances are that a friend of yours has told you what they are working on. Let them decide when they want to start the buzz.
6. Give credit. It is probably not a good idea to post to your work distribution list a word-for-word the answer to a question that was asked in a channel. Some of the people who provided you with the answer probably work with you. If the product of your labor depends on another.s help, give them credit.
7. Thank the people who help you. They probably took time out of their very busy day with no personal benefit, just to help you succeed. Make their day by letting them know how positively beneficial they are.
8. Cite your sources! If you are expanding on someone else.s research, state it in your paper, blog, or slide deck. If your idea came from somewhere else, state it.
9. Review other.s research. All researchers need a sanity check and an extra pair of eyes to go over their work before it is released.
10. Make yourself available. The entire community (not to mention the entire security sphere) benefits by people acting as resources for other.s improvement.
11. Choose your conduct wisely. People remember. Shady behavior is noted quickly. A lot of security researchers rely on each other as trusted sources. If you behave badly, your story will live forever.
12. Preserve anonymity. Unless explicitly stated, do not expose another.s identity, associations, or opinions without their permission.
I have been doing a bit of reading on social network graphing and general social network theories and concepts. Visualization techniques can be very effective when attempting to analyze social networks and the resulting gathered data. This is evidenced by the paper entitled "De-anonymizing Social Networks" by Arvind Narayanan and Vitaly Shmatikov. If you are interested in social network graphing and/or general visualization give this paper a go.
Time for a mishmosh post. I presented at Source Boston and CarolinaCon conferences this past week. Both were absolutely awesome. Both the people and talks were fantastic. I promised everyone that the paper and source code would be available this week, so here are links to both.
Anti-Debugging - A Developers View (PDF Format)
Paper associated Visual Studio solutions and source code
If the above isn't enough of a post for you interested readers, I submit for your viewing pleasure... the three best Muppet singing voices in history! Have a great St. Patrick's Day!
Source Boston conference starts tomorrow. I will be speaking Friday morning. Anyone who will be in Bean town this week please drop me an email (txs@donkeyonawaffle.org). I'll be available for drinks/food/general mayhem.
New update to WinDbg was released on February 6, 2009. Get It Here.
Changes:
Numerous bug fixes and documentation updates
Numerous updates to improve 1394 debugging (see relnotes.txt for details)
support using ..process /p .. in kd -kl, so you can see user mode memory in the appropriate process context (which means user mode stacks, !peb, etc.)
The papers and presentations from Blackhat 2009 are becoming available as we speak. They can be found HERE. I plan to devour and comment on some of them this week... (assuming I get the time).
I just read a new blog post on the The Top Ten Vulnerability Discoverers of All Time - by Gunter Ollman at the Frequency X Blog. I have the utmost respect for the X-Force folks, many of the best researchers and security practitioners in the world today have come from this camp over the course of the last 15+ years. And to be completely honest, I understand why this information would be of interest to the blog readers (I probably would have published it as well had I owned it). However, I hate what it represents...
At one point in history, vulnerability research and discovery was about fixing the bugs and stopping the bad guys from abusing the holes. Somewhere along the line it became a game of "I'm cooler... I found the most interesting flaw!". And finally, as if that wasn't bad enough, it appears as if the latest bragging right is "I found the MOST flaws!". My thoughts on this is.. "Who Cares?!". Let's get back to fixing things because it's the right thing to do. Let's get back to working with the vendors to make the computing world safer. Let's stop worrying about flaw counts and who's the most uber. Sadly.. I don't think we can go back in time - R.I.P. the good old days.
Page 1 of 5 [Next]
