We’ll be right back after this short PSA.
Hello everyone,
I’ve been quite busy with projects outside of technology this week, both new and old. To break down a current problem, the time investment needed for these to get the necessary focus depends on my own potential boredom. Life is very dynamic and unpredictable right now. School is shifting in purpose from computer science to system engineering and back, and soon I’ll be interviewing for scholarships. These two factors spring me into action to gather my work into a portfolio.
As I’ve had much success helping out with friend requests and game development/metaverse type work, that’s where I will be playing my cards in for education. I recently helped solve a problem through some offhand reversing the unity audio engine tool wwyse to look at how volume for sound effects are handled. Short answer: very loudly. This let me help a friend fix an ogg file by increasing volume as part of their game. The current setback to the disposable phone project is no need from family anymore to make this process cheaper. The option of price vs convenience is always one to consider with technology, and in some instances I’ve learned that convenience comes out on top. That will be the theme of this blog as I go over some of the dilemmas my current projects are facing which are holding me back.
The successes are often seen as an “I can do that” moment by many. Indeed, anything someone puts their mind to can be done with a little hard work and the willingness to participate, learn and achieve. The failures on the way to progress can also be interesting, as they show the physical, mental, and sometimes emotional toll one takes trying to make, break, or build a system for business or personal use. The thing my recent classes have taught me is that cost, time and practicality must be considered for development projects. I’ve been seeing real world consequences of not planning my projects recently and for that reason I’ll be sharing them in today’s blog.
When considering cost, something cheap up front might not end up being cheap to put together in the long run. Hardware reverse engineering has taught me that while you can do things the hard way just like with software, it comes at a price somewhere else. The project I’m working on aims to study a specific smart lock and how using its onboard ARM chip, run a lite and open source version of linux capable of supporting open API commands. The motivation for this is simple, because a dynamic analysis revealed that this lock’s ecosystem is absolutely riddled with egregeous security practices. I’m sure that showing others something like this would be a good motivator to start off in the right track, which is where this project is shifting as a result of the current work.
Hacking hardware is not cheap if you don’t have workshop to supplement it. What started as a lock purchased for $60 from ebay has turned into a potential $200 investment in electron microscopes, continuity testers, soldering irons and other tools. The same issues happened when I was trying to build a USB Bluetooth emulated keyboard from the Phantom Lapboard. The complications means a lot of this is making your own path which other users have not documented quite the same way you would have. Eventually you do make progress and learning happens when you acquire the necessary components. Learning from past and present failures is key to building practical software and hardware tools.
The most important point to this type of work comes from your physical health. Imagine working without tools such as electrostatic wrist mats and pads, and the next moment you might have forgot to wear safety goggles and caused an injury to yourself. Reverse engineering and other computer work is revolving around a central topic that most people take for granted: eyesight. Working with VR, smaller screens, and looking at PCB traces without necessary workbench tools or knowledge means that your eyes might stop working correctly and start seeing literal splotches from fatigue. This is serious. People take for granted certain things we can all do day to day, not thinking about a push for accessibility in virtual spaces. Developers can and should more often think about the health of themselves and their target audience. If you take nothing else away from this blog, take a step back from how you carry out your daily tasks from time to time, think about them, and have a moment to ask “how stupid does this actually look?”
On a lighter note, the practicality of each project varies heavily. Who wants to use an old GPS for a desktop clock? Who needs a lapboard game console peripheral to work as a Bluetooth keyboard? Another example if a Microsoft Zune repair I have sitting around. I’ve diagnosed the Zune’s issue to stem from the ZIF drive cable associated. There is a more elegant solution with old iPods and compact flash cards. Why does the Zune not allow something like this? A project started by someone in the open source community would be an ideal spot for this. Again, this comes back to practicality for the user to make this.
While science says ‘why not’ to these types of projects, the audience and practicality of doing this stuff matters too. It comes back to ethics, making enough to live where you do in the world, and so on. What I set out to accomplish at school was to create the experience and the environment needed to make work happen that I cannot accomplish on my own. the practical work I can do as a result lies in gaming, collaboration and working with my mentor to establish my portfolio, learning plan. While I maintain work in another job field, my intended work will be in the area of systems and computing should my collaboration goals be met. At the same time, continuing to pursue the areas and projects with people I am involved in is just common sense. You take what you do as far as you can and you see what happens, that’s practical.
When developing or researching a new system on your own, expect a great big timesink. When doing security research for hackerone and bugcrowd projects, I would often spend weeks planned out on what areas of the software to look at. While I’d consider this unsuccessful, I saw great potential in finding vulnerabilities as a way to get myself motivated about learning, software development, and revisiting my area of experience outside of restaurants. Sure the pandemic changed the world, but the job did not keep up and here I was waiting for the right chance to succeed in a knowledge area I had. This led to hard work and building upon both the successful hacks and the failed ones. Laying it all out to see, you can find that the amount of time to learn and master a system can take a lot of well directed focus over a long period of time.
The most important thing is to consider for time with open source development is documentation. Document everything, and if you don’t succeed in the project, put it somewhere where someone can pick up the torch. This intrinsically comes back to showing value in your work, and while it’s not a portfolio, the scraps can really help uplift and empower someone who saw a project as unfeasible go from a mountain to a “oh I can do that” molehill. For that reason, I mentioned that the OpenTom GPS was working on a new system in my last blog, and the bug reports I put on github also reflect that. Putting time into a project will yield something, so be sure to take note of what work and areas were covered to reference later on.
To continue with the lock arm reverse engineering project, I’ll be collecting my information gathering into a file and look for the resources and people to help work progress. I do believe this one has potential and I intended to explore all available options to achieve this. The next blog post is up in the air concept wise, but I’ll post an update monthly like these as needed. Apologies for being lighter on content this month.
Stay safe.
