I'm a consultant for teams working with embedded Android products.
I'm also available for more traditional mobile development projects, but embedded Android is where I find a lot of teams struggle to find resources.
-
I've found that many companies use Android-based hardware hoping to leverage the Android ecosystem's size, but run into roadblocks when people who are more accustomed to mobile development attempt to design for an embedded use case.
I've spent the majority of my career working on high-profile user facing Android products. I'm familiar with the unique challenges in the space, from old/outdated hardware, to reliability concerns, and more.
I'm available for up to 20 hours a week at this time, please reach out to dev@croc.studio
-
And while I am interested in consulting/contracting, if you are currently searching for full-time embedded Android talent consider reaching out. I've found that when there is already a team in place, having someone familiar with the space available to drive high-level architecture can enable some pretty great outcomes without taking on additional headcount.
I'm recovering from a broken leg, so I can't easily follow a normal Peloton class.
There are guides for running non-Peloton applications on the tablet (which runs Android), but there's no way to keep track of any of my stats.
So I reverse engineered the official applications and found a route to send serial data to and from the bike's sensor module. From there I was able to retrieve live stats, and wrote an app that overlays those stats over other apps
The result is being able to watch content from any app that runs on Android while still getting the same live metrics as you would within the Peloton app
I got called into the administration office for running Linux off a USB stick. It wasn't for anything nefarious, I was hoping could have my development environment stick around, since the Windows environment would reset everything after you logged off
It was clear the principal had no idea what this "Linux" thing was, but the IT person did his best to make it as spooky and evil as possible unfortunately.
I don't remember what came of it, but later in the year a computer virus hit a few computers in the school, and I distinctly remember a multiple people thinking I had done it...
Of course I would never, I was the last person who would want a run in with that IT guy again all. But no call into the office that time, and in retrospect I wouldn't be surprised if it was a simple misconfiguration being called a "virus" since it allegedly only affected teachers' classroom PCs
I was reprimanded for using PuTTY to log into a remote server for a course I was taking through the local community college in high school. The head IT person said that the white text on black background looked too much like "hacking" and that it wasn't allowed. I switched to black text on a white background, and everything was good again.
It listed all the built in help, basically masses of text scrolling down the screen. I assume the teacher thought I was hacking the computers or something, scared them.
To be fair, I was hacking the computers, but not when they were watching. Turns out the password file used very simple reversible encryption, but we only used our powers for good, and games.
Linux does sound evil, is it from one of those eastern european countries? I hear it's like communism
I just moved to NYC from Durham, NC, and I braced for the change in COL.
But I don't think it's as bad as people say, and I think a big part is transportation.
The 1 month Metrocard costs about what I was spending on gas in a month of commuting with a 124 Spider (not the most fuel efficient car, but very far from a gas guzzler)
Once maintenance and insurance are included, the Metrocard is cheaper (as I take trips outside of work).
-
I can also walk to most errands I previously had to drive 15-20 minutes for (40+ minutes total after parking and traffic).
Besides saving money, the time saved is pretty valuable
I tried to get developer access via a form and never got a response, so I tried sending a message the head of the infotainment on LinkedIn
Thankfully he was able to get my application to the dev site moving... but unfortunately, they required a business use case to get an API key once you had access to the site.
So I tried to pick the API key out of the app.
They had the most novel obfuscation I've ever seen for an app's API key
The key was inside the image data for the launcher icon
There was a weird transformation applied to it too, so instead of trying to reverse engineer it I just fired up Charles and intercepted it from there
With the API key and the documentation for the API from the dev site I was able to write a program that started preconditioning my Volt when I left my apartment (the car was in an attached underground garage, so it'd be at the right temperature by the time I got down)
Nice! I've been trying to do some RE myself to no avail. This project (https://github.com/TheCrypt0/yi-hack-v4) maintainer puts a paid DRM atop the main functionality (enabling rtsp streaming for Yi cams). I tried bypassing the DRM by replacing the MC command in ghidra but it didn't work. Do you have any learning resources you can share so I can bypass/crack this DRM?
Unfortunately I don't have anything that would be helpful
Reverse engineering Android apps is pretty easy because there's a very well defined application format, and a ton of hints about the original source in the bytecode
Your situation sounds a little more complicated than that
Found the call that added the header for the API key to each request (even with Proguard's obfuscation string literals are preserved, so searching for "x-api-key" worked)
From there I followed the call chain to their transformer, then looked at the input for the transformer and it was loading a subset of bytes read from the same resource as the launcher icon (and sure enough, opening it in a hex editor there was some weird "garbage" that I'm honestly surprised Android doesn't choke on)
There's not much to show though, I have a bad habit of not putting stuff in VC "because it's just a quick experiment"... then it becomes a long term project with no backups
You can get away with ELM327 based readers (the cheap bluetooth/Wi-Fi OBDII readers you see on Amazon/eBay) if you want fairly standard data like speed, and some manufacturer specific data in the form of PIDs (https://en.wikipedia.org/wiki/OBD-II_PIDs)
If you want more involved data, or to send messages, it's mostly sniffing, doing an action, and seeing what changes.
`can-utils` has a nice UI for this, which lets you filter messages that don't change easily.
(Also, I've actually never seen a `.dbc` file before, but it looks like a map of PIDs, usually you [or the community for your car] have to reverse engineer those with the sniffing method, afaik)
-
The ELM327 can technically stream all the CAN messages on the bus and do that type of sniffing, but it has a very small buffer and gets completely hosed with chatty cars.
I personally use the MCP2515 with a Raspberry PI for more involved car hacking.
The electrical modification mentioned is needed for the most common MCP2515 modules because the PI isn't 5v tolerant, but it's an easy enough fix
I have two of them hooked up to a Raspberry PI (one for each of my car's CAN busses, some cars have more), and that with `can-utils` has gotten me pretty far.
People should be aware that many of the cheapo "ELM327" readers on Amazon/eBay are counterfeit chips that merely identify themselves as ELM327. They do not perform as well as the real chip, but may be good enough for reading your check-engine code. For example, I had a fake one that choked if I tried querying engine RPM in a loop, while the real deal had no issues.
I've had success with clone ELM327 for reading stuff like RPM in real time, but it is hit or miss.
They're just generally slower and usually missing features of the newest ELM327 revisions.
The problem is if you just search for ELM327, most of them will be clones, so I just use the MCP2515 when I need lots of data, and use the ELM327 for basic stuff
If it's in the budget, I would highly recommend the Macchina M2[1], especially if you need to access more than one bus at a time. It's based on the Arduino Due, with dual CAN transceivers (and LIN). It has a lot of bells and whistles - but can be simplified down to just a can sniffer if needed. I'm currently using one with SavvyCan to reverse engineer a vehicle for a project, and it has no problem keeping up with the high-speed network.
Remote: Yes
Willing to relocate: No
Technologies: Android, Embedded Android
Résumé/CV: On Request
Email: dev@croc.studio
I'm a consultant for teams working with embedded Android products.
I'm also available for more traditional mobile development projects, but embedded Android is where I find a lot of teams struggle to find resources.
-
I've found that many companies use Android-based hardware hoping to leverage the Android ecosystem's size, but run into roadblocks when people who are more accustomed to mobile development attempt to design for an embedded use case.
I've spent the majority of my career working on high-profile user facing Android products. I'm familiar with the unique challenges in the space, from old/outdated hardware, to reliability concerns, and more.
I'm available for up to 20 hours a week at this time, please reach out to dev@croc.studio
-
And while I am interested in consulting/contracting, if you are currently searching for full-time embedded Android talent consider reaching out. I've found that when there is already a team in place, having someone familiar with the space available to drive high-level architecture can enable some pretty great outcomes without taking on additional headcount.