Developer Spotlight: LadyX of Team Unlimited
Developer Spotlight is a series in which we attempt to get to know a little more about the developers who make the applications, exploits, and ROMs that we feature on Pocketables. This week, we’ve got an email interview with LadyX of Team Unlimited, the team responsible for the DirtyRacun, JuopunutBear, and LazyPanda S-OFF exploits for the HTC EVO line, and several other devices.
For those who don’t know you, how would you introduce yourself?
I am a tinker by trade and by nature; flaming red hair and a pension for defying gravity. I call the Pacific Northwest home but can be found traveling all over.
How did you get involved with Unlimited.io, and what is your exact affiliation?
Let’s just say that IRC has a way of networking people. hyuh found me in #htc-evo-4g-lte, where we were both helping people with CyanogenMod on the LTEvo (Jewel). I was officially brought onto the team in August of 2012 as an equal partner.
How did you first get into the EVO world?
I had been rooting and modding Androids since the original Moto Droid. I really got into it with the OG EVO and have been elbows deep since. Prior to Android, I was pwning iPhones and modding WinMo phones (back in the day).
What do you do for hobbies and entertainment that’s entirely not Android related?
You could say that I am a jack of all trades. I ride horses, motorcycles, jump out of perfectly good airplanes, and I spend a lot of time with my friends.
What do you ride?
A black and red R6 named Grendel.
What can you tell us about Team Unlimited?
Team Unlimited was born in March of 2012 as the result of a chance meeting between hyuh and Fuses on IRC. At the time, they were looking at the behavior of the HTC Sensation and similar devices that had been ‘bricked’ as a result of setting S-ON on a device that was running the Revolutionary bootloader.
When the HTC Unbricking Project had achieved its goal of recovering the affected devices, they continued to examine the new security of the affected devices in the vague hope of running unsigned code and from there finding a new S-OFF exploit. After proceeding down many blind alleys, something interesting happened and a phone booted with an unsigned bootloader. Within a few days, an IRC exchange proclaimed ‘lol, S-OFF with a paperclip’ and the then unnamed JuopunutBear exploit resulted.
Some time was then spent on making a usable exploit program and testing. When the exploit was ready to release, we discovered that we had no name for our team. Finding it difficult to think of a name, we turned to internet random name generators, with some amusing results. When one of these suggestions included Unlimited, and then we knew we had our name.
When the HTC EVO 4G LTE was liberated from customs, we released LazyPanda using an exploit that we had previously discovered.
We continue to build exploits where we see demand and room for growth.
Has anyone at Unlimited ever gotten a “stop it” nastygram from HTC?
Nope.
On a similar note, has anyone gotten a job offer from HTCDev to test out their hboots?
Nope.
A lot of people complain there are no one-clicks like in the rEVOlutionary days. Care to tell them why?
There are two reasons for this, the first being that when previous S-OFF exploits were discovered, there was no such thing as HTC Dev Unlock. This meant that there was no need for people writing exploits to be concerned about the behavior of custom ROMs and their potential adverse effects on the exploit or the potential that using the exploit on a custom ROM could cause the phone to become “bricked.” It is not possible to test on all ROMs for even a single device; therefore, we support only official ROMs (RUUs) and force people to be in stock condition before running our exploits. In almost all cases where problems have occurred, it has been the result of not being in stock condition. For this reason, we have made being in true stock condition a pre-requisite of our exploits.
Second is education. We feel that there is a consumerist attitude among many of the newly initiated users in the Android community, where it is expected that everything can be done without the need to gain even basic skills or knowledge of the device that a user has. While it is possible to proceed in this manner, HTC devices with S-OFF are not a suitable sandbox for such users, as it is possible to brick devices quite easily under these conditions. For these users, the HTC Dev Unlock – despite the restrictions it imposes – is a much safer option. The problem is when people think that S-OFF is ‘cool’ without understanding the consequences of having a S-OFF device; we cannot and do not seek to stop these users from obtaining S-OFF; we do, however, force them to become at least a little familiar with the basic tools for maintaining and supporting their devices. This is done in the hope that it will reduce the workload on both our team and other developers in the future by making it unnecessary to endlessly answer questions on how standard Android tools such as adb and fastboot work.
Could you walk us through how one of the EVO exploits worked?
Nope. If I told you I’d have to kill you, or at least tie you up and put you in my trunk with duct tape over your mouth. There is a reason that only three people know how our exploits work completely, and all three of them are on the team.
For someone who is interested in getting into crafting or researching exploits, where should they start?
Read, read, and read some more. Then tinker until you find something neat. Share. Profit!
Is there any brick potential with Unlimited’s offerings that can’t be fixed now?
Anything is possible, but they are as safe as we can make them. The chance of bricking your phone with a custom ROM is greater than the risk when achieving S-OFF, as long as you follow directions. 99% of bricks that we’ve seen have been because of failure to read and follow directions, and these are all repairable. The other 1% is freak accidents (read: kids running by and yanking the phone out of the computer while the process is running – true story).
The reason that we support only certain OSes with our tools, and the reason that 64bit OSes are NOT supported, is because the drivers are unreliable. While it is possible to use a hokey work-around to use these OSes, there are also very good reasons why we tell you what is supported and what it will work with. We have tested and tested and tested some more, and the documented instructions on our website is the safest way to use our tools and avoid bricking your device.
As far as you know, is there anything unlimited.io’s s-off exploits are doing that’s illegal? I’m wondering what the DMCA might have to say, but honestly don’t know.
There is nothing illegal about S-OFF exploits. Secureflag is not copy-protected, and we are not using any other parties’ work inside our exploits. Obtaining S-OFF doesn’t compromise the device, nor does it open in any way to access the users private data.
Why the secrecy on exploits?
Our team made a decision to keep our knowledge to itself, and if anyone is unhappy about it, they are welcome to create their own exploits and share them with the world. We are already battling with kangers stealing versions of our tools and reposting them (with bad instructions!) on their own websites and blogs, and even a few “all in one” kits that will only brick your device or fail to run. There is a reason that we ask everyone to come directly to the source – we built the tool and they didn’t. Who better to help you than the people who created the tool?
Have you guys made one cent off of any of this?
We get donations from time to time; $5 here, $2 there. It ends up helping us purchase devices to test on, or paying for things we need to do our job. We don’t ‘make money’ on our tools, though.
What’s your programming/hacking/coding past?
Nothing that I can mention publicly.
Anything you’d like to get on a soapbox about?
Respect and self-entitlement.
Every so often, we get someone in our support channel or posting to our thread on a forum about how they are unhappy with the way we write our instructions, the support we give them, or the fact that we don’t support 64bit OSes or Windows 8. I’m not quite sure why people feel so entitled to having everything the way that they want it, and then decide that the way to get it is bad-mouthing our team or one of its members.
What seems to elude this handful of people is the understanding that we make this tool for the entire community for free. We make the best instructions we possibly can while still leaving a barrier for entry (unlocking the castle doors without knowing how the cannons work is bad), and we attempt to support every person who comes to us for help as best we can. We absolutely expect people using our tools to have a basic amount of knowledge, and if they don’t, we will tell them to read up on what they are lacking (fastboot, root, etc). We only support the tools that we make and will not support anything else.
Any developers, or developments, you think the readers should be aware of?
We don’t generally deal with ROMs, which is where most developers work. We do however suggest that users watch the official CyanogenMod work. This is a hub of development activity in the Android community and is where end users can get a real feel for what Android is including in versions yet to be released by their phone maker. We make our tools so that people like these can provide the Android community with this experience.
What phone do you use as a daily?
HTC EVO 4G LTE (Jewel) is my current daily device, and previously it was the OG EVO (Supersonic)
Is anyone at Unlimited working on cracking or bypassing HTCDev’s bootloader unlock token generator?
We’re working at lots of things, but until we are successful, we don’t publicize any of our works-in-progress.
What do you think people don’t quite get about what your team does?
People sometimes misunderstand why we do not release things sooner, when we have been looking for testers for a while. This is usually because we are unhappy with the number of safety checks in the tool we are creating. We do as much as we possibly can to make our tools safe to use. Getting S-OFF on a device entails certain risks, and we always take the time to eliminate or minimize these risks. This means that there will always be a delay between an exploit being identified and it being released. Under no circumstances is this done to build anticipation or in some kind of attempt to obtain donations.
