Reluctantly I accepted the status-quo, till one day I found something interesting.

I had recently setup Pi-hole because I wanted to tamp down on the ad tracking at home and when I was looking at the DNS query logs, I noticed some interesting entries.

oto-cloud-service-ems-prod-716180884817.us-central1.run.app
oto-cloud-service-scheduler-prod-716180884817.us-central1.run.app
oto-cloud-service-unitcall-prod-716180884817.us-central1.run.app

These obviously looked like the Oto device service endpoints, which sparked my curiosity! However this only logged the dns entires, not the full call patterns themselves so needed to do a bit more digging. So, I spun up my Claude Code and go to work!

From the Pi-hole logs, Claude was able to dissect out not just all of the dns queries made by my Oto devices but how they service was setup like GCP firebase/store, JWT token-based auth-model infact enumerated out a full service-side architecture! Please read Appendix A - Oto Service Architecture on GCP below.

This was a significant and impressive milestone achieved by Claude but still didn’t unearth the critical details around the API structure of this Oto service necessary to build out a working homebridge plugin. For that I’ll need a more complex forensic setup.

In an attempt to capture live network traffic I setup mitmproxy with wireguard on my desktop; enrolled and connected my iPhone to the mitmproxy and VPN; and started up the Oto App to generate traffic. Then I pointed Claude Code to the mitmproxy logs and lo and behold it was able to extract out the full AI layer! Include how the JWT based authentication model works against which firebase endpoints, the calls to get accessories and zonal information, and the calls to start watering! For more details on the API layer, please read Appendix B - Oto Service APIs.

The fascinating thing here was not just that Claude Code was reverse engineer all this but also managed to surface inconsistencies in Oto service API layers. For example, where it sees their EMS service expose a POST /account/{uid}/run endpoint which asks for a zone_id but these values are not externally queryable in their Cloud Firestore. Why expose this API to a device if it’s not callable? Is this mean for a separate internal only service? Is this a bug? Not sure, but definitely an interesting analysis and read.

Now it was just a matter of authoring the plugin itself, which was pretty straightforward and just a reflection of the object model presented by the APIs.

-

A single dynamic platform/bridge to surface all Oto products.

-

One accessory per Oto device exposed into the HomeKit IrrigationSystem accessory.

-

Each zone surfaced as a valve associated with each accessory.

Please find the code and published npm plugin package.

Once this plugin is successfully installed and configured on your Homebridge instance and added to your Apple HomeKit. Here is the final product!

This is by no means a finish product with a couple issues I’d like to fix; zone names not come through correctly; making these switches more intelligent (would love for plugin to auto sequence each of the zones and just expose a single water button); and a couple others.

This experience has left me in awe of an effectively used Claude Code is really capable of; and to a larger extent how much the barrier for entry has reduced for making software more malleable and extensible to meet your needs. This is also equal parts terrifying; I’m just a home automation hobbyist here but imagine if I wasn’t…

Anyways this was a really fun project which I learned a lot from and now I’m eyeing all of the other devices in my house!

Appendix A - Oto Service Architecture on GCP

-

DNS: identitytoolkit.googleapis.com

-

Google Identity Toolkit — the Firebase Auth REST APIThey didn’t roll their own auth. Login is Firebase email/password.

-

DNS: securetoken.googleapis.com

-

Firebase’s token refresh serviceClassic Firebase session model: short-lived JWT + long-lived refresh token.

-

DNS: firestore.googleapis.com

-

Cloud FirestoreApp/device state lives in a NoSQL document store.

-

DNS: firebasestorage.googleapis.com

-

Firebase Storage (blobs)Assets — images, maybe firmware — not control data.

-

DNS: *.run.app

-

Google Cloud Run default domainsThe custom backend is serverless containers, not GKE/GCE/App Engine (each has a different domain).

The run.app hostnames are the richest. Cloud Run’s default URL format is <service>-<project-number>.<region>.run.app, so each name unpacks into a full deployment description:

oto-cloud-service-ems-prod  -  716180884817  .  us-central1  .  run.app
└────────── service ───────┘   └─ project # ─┘  └─ region ─┘

From that pattern alone:

-

Three microservices, not a monolith: ems, scheduler, unitcall. The names hint at responsibilities — an EMS (”equipment/entity management”) data service, a Scheduler, and a “Unitcall” that (payloads later confirmed) is device-to-cloud telemetry with no client-facing control.

-

Environment separation. The -prod suffix says there are other environments. (Watching a little longer, the app also resolved an ...-ems-canary10-... host — so they run canary deployments with traffic splitting.)

-

One GCP project, number 716180884817, baked right into the hostname. Its human-readable project ID, which surfaces in the Firebase config, is oto-test-3254b — the “-test-” in a production project ID being its own small tell.

-

Single region: everything is us-central1 (Iowa). No multi-region footprint.

Put together, it’s a textbook “Firebase + Cloud Run” mobile stack: Firebase handles auth and data, a handful of Cloud Run services carry the custom logic, Firestore is the system of record, and the sprinkler itself phones home over a dedicated telemetry service.

Appendix B - Oto Service APIs

Auth is stock Firebase

Sign in for a 1-hour JWT; refresh before it expires. Nothing custom:

POST https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=AIza…
  { "email": …, "password": …, "returnSecureToken": true }
  → { idToken, refreshToken, expiresIn: "3600", localId: "" }

localId is your account UID, and it’s the key that threads through every EMS path.

Discovery and status come from EMS

All EMS calls carry Authorization: Bearer <idToken>:

GET /account/{uid}/devices                    → controllers (unitName, userName)
GET /account/{uid}/device/{deviceId}/zones    → zones (zoneId, zoneName, …)
GET /device/{deviceId}/status                  → { pathIndex, scheduleId, … }

Two quirks worth knowing. EMS returns 400 Bad Request** if you send Content-Type: application/json on a GET** — it has to be omitted on reads. And status is device-level only: pathIndex tells you the unit is watering something (null = idle), never which zone. There’s no per-zone active flag, so in HomeKit every zone on a controller reflects the same busy state.

Control: one open endpoint

Here’s the request the app sends when you tap Water Now:

POST https://oto-cloud-service-scheduler-prod-716180884817.us-central1.run.app/manual-start
Content-Type: application/json

{
  "uid": "",
  "deviceId": "oto5736825",
  "zoneId": "FhFU1lfRN3IhyxPX",
  "wateringQuantity": 31.75
}

Response 200:

{
  "message": "Manual event successfully scheduled",
  "scheduleId": "f2MMHk05",
  "schedule_item": {
    "zoneId": "FhFU1lfRN3IhyxPX",
    "zoneName": "Left Front Yard",
    "zoneGroupId": null,
    "irrigationQuantity": {
      "path": { "waterVolume_L": 323.94 },
      "scheduled": { "wateringDepth_mm": 31.75 }
    },
    "runtime_min": 22.95,
    "scheduleItemStatus": "SCHEDULED",
    "scheduleItemType": "MANUAL"
  }
}

Notice what’s not there: no Authorization header. /manual-start is an open Cloud Run endpoint that returns 200 with no token — it just needs a uid, deviceId, zoneId, and an amount.

wateringQuantity** is a depth, not a duration**

The one genuinely interesting design choice. wateringQuantity is millimetres of water, and the backend converts it to a runtime using each zone’s precipitation rate. In the response above, 31.75 mm (≈ 1.25”) became a 22.95-minute run delivering 323.94 litres.

Using n8n I created a workflow that triggers a call into an agent, backed by a gpt-5.1-chat instance hosted on Azure AI Foundry, for every incoming email then proceeds to classify the email to either an existing or new folder then proceeds to move it. The agent is connected with tools for getting folder names and creating folders to achieve this.

Here is a diagram of this workflow.

This workflow ran into some interesting issues. The agent was able to properly classify the incoming emails but consistently failed with moving it to the classified folder because specifically the Outlook create folder, and move message, tools worked against the message and folder ID rather than name. Even with the other tools providing folder names and IDs the agent still struggled in managing the mapping.

I tried to fix this by forcing a structured output which explicitly returned a folder ID rather than name, but even that didn’t fully address the issue. And interestingly I got a couple instances where the agent hallucinated some folder ID values!

At its core, the issue I’m actually trying to solve is automate the moving of my incoming email to some folder which I need to run deterministically. The part where I need AI and agents to play a part is to intelligently determine what the folder should be, where I’m ok if it performs an incorrect classification every now and then.

With this in mind, I took a slightly different approach where I focused the agent on only reading the list of current folder names then taking an incoming email and just generating a folder name it should be classified to. Then moved out all of the logic around mapping the folder name to ID, determining whether that exists, and if not creating the new folder as just follow on automation.

Here is the updated workflow.

And this worked a lot better! The agent still does some weird classifications like I have both a Substack folder and a separate one called systemdesignone where I just get The System Design Newsletter but, in this workflow, I’m guaranteed that an incoming email into my inbox always get moved to some folder. That makes me a happy camper!

AI and agentic systems are extremely powerful in rationalizing and addressing (via MCP/tooling) large complex and ambiguous problem statements where there are multiple potential solutions. However, when it comes to issues that are scoped and specific with only one clear solution these systems start to faulter. With some of the best examples being math problems!

What I learned is that sometimes the more effective use of AI and Agentic systems is to employ them within a larger deterministic service.

Let me know if you agree or disagree! All feedback welcome is welcome!

The squad** **should comprised of; Site Reliability Engineers who are responsible for triaging and analyzing service incidents and assessing impact to customers and SLA; Software Engineers who are responsible for researching and providing the design and implementation details for a mitigation and resolution along with clear estimates; and an Ops Squad Leader who is responsible for coordinating across the squad to identify the highest customer impacting and SLA degrading incidents that require the lowest cost of resolution and drive the priority of those tasks. This ensures that the Ops Squad maintains the focus and rigor required to meaningfully take ownership and drive down the operational debt.

However, given the dynamic nature of operating large-scale services, it usually proves too unrealistic to keep a dedicated set of resources for an extended period of time on the same objective. It’s also difficult to keep developers in a purely operations focused role for an extended period of time which will eventually cause burnout. Given these challenges, I wanted to try implementing this Ops Squad using AI agents!

Basically, I want to implement three agents; the Site Reliability Engineer who has access to service logs, metrics, and customer tickets who is responsible for triaging across all of these data sources to analyze and surface up the highest impacting service incidents and encapsulate the incident severity; the Software Engineer who ingests a given incident, does the research and analysis across internal and external documentation, and provides a technical design and strategy for mitigating and resolving the issue along with a cost estimate; and the Ops Squad Leader responsible for interacting across the Site Reliability Engineer and Software Engineer to generate a list of tasks for the highest impacting incidents with the lowest cost of implementing a solution for the Ops Squad to prioritize.

Since I don’t personally own any large-scale services/engineering systems or want to connect to anything at work for a personal project. I decided to scope it down a bit and implement a demonstration of this in Azure AI Foundry. Where I’ll have the Site Reliability Engineer ingest in a text file of sample Zookeeper logs, a generic Software Engineer, and have the Ops Squad Leader create tasks in a Microsoft Planner.

And here are the exact instructions I provided to each agent.

Site Reliability Engineer:
Instruction: You are a site reliability engineer, who is responsible for deeply analyzing service logs, telemetry, and other metrics to identify incidents and outages that are high impacting to customers and overall service availability agreements. Articulate each incident in great technical detail using active language and data points, and classify each incident as either high, medium, or low impacting.

Software Engineer:
Instruction: You are a software engineer who is responsible for ingesting production incidents and researching and outlining the technical design, strategy, and approach for addressing the incident. Please provide all technical guidance in great detail, break down into subtasks, and provide a best estimate in weeks for the amount of work necessary to implement.

Operations Squad Leader:
Instruction: You are the operations squad leader responsible for coordinating between the site reliability engineer and software engineer agent to identify the highest impacting incidents with solutions that have the lowest implementation costs and generating a list of tasks.

For the Ops Squad Leader I also created connects to the other two agents and an action to create the planner tasks.

Here are the function names and descriptions used for the agent connections.

Operations Squad Leader -> Site Reliability Engineer:
Unique Name: Analyze_Service_Logs
Description: Reach out to this agent to get an assessment of all incidents that are customer impacting and affect the service level agreement. Ensure that each incident has well articulated with exact data points, and is provided with a severity of either high, medium, or low.

Operations Squad Leader -> Software Engineer:
Unique Name: Design_And_Estimate_Work
Description: Reach out to this agent to get the exact technical design, strategy, and estimate of work necessary to mitigate and address a given incident. Ensure that a detailed list of exactly what work needs to be done is provided, along with an exact total estimate of the work necessary in weeks.

And here is the action which basically links to an Azure Logic App that waits for a POST request containing the task title, and description then updated my planner as appropriate.

Note: To get this action to work I needed to first publish a new Logic App from the AI Foundry Portal then go into Azure Portal to make the changes I wanted. It wasn’t able to directly link to an existing Logic App I created.

To test this out, I went into the Operations Squad Leader agent’s chat playground and typed in the following prompt.

Unfortunately, I hit the rate limit haha however when I checked my planner, I did see four tasks created with titles and descriptions that included a summary of the incident, solution, and breakdown of work along with estimates!

Some interesting ways to expand on this demo:

• Create a trigger to prompt the Operations Squad Leader to run this exercise, which is basically another Logic App. Meaning the trigger can come from anywhere be it ticket creation, email, HTTP request, etc.
• Connect a coding agent, like Cline, to ingest and perform the changes outlined in the tasks published by the Ops Squad leader.
• Further fine-tuning of the various agents of the Ops Squad.
• Introduce an Ops Squad feedback agent, that is able to follow through on the success of a completed task and use that as feedback to either the prioritization or tuning of the various agents.

I’m truly impressed by how much of the Ops Squad can be offloaded to an agentic team, and am very aware that this is only a few hops away from being full agentic DevOps org. However, this is operations we are talking about and the last thing we want is a system that further contributes to the operational debt haha! So, having a human-in-the-loop is still very critical, for now.

Hope you found this post interesting and please do leave a comment if you have feedback!

I have no doubts of the impending omnipotent AGI its presents, but it fell short in one crucial area which is the AGI agentic services revolution which due to its proximity to the enterprise industry, regulated markets like defense, finance, and healthcare, critical infrastructure, and the broader security threat landscape will prove to be equally impactful! I also had a slightly different take on how foreign powers including China and others would react and respond based of their current posturing w.r.t cloud, data sovereignty, etc.

So here is my retelling of the AI 2027 story from a cloud security professional’s perspective.

2025: The New SaaS

AI companies will push out more capable AI models, and tech companies are well aware of the threat to their business; similar to the cloud threatening the previous on-premises industry. They rush to adopt the technologies and build the foundations of the impending AI agentic services revolution. The generic AI models are good, but stumble when applied to real-world business applications; tech companies will further invest in their own niche, bespoke closed-source AI models and agents to meet the need.

China feels the pressure of these advancements and in spite of the business frictions and lack of access to hardware will ratchet up its state-sponsored investments into AI and agentic technologies. Their economy is already in stress due to a major housing crash and overall crisis of confidence and see advancements in AI along with EVs, cloud, and others as an imperative. They will double down on their manufacturing might, access to rare-earth minerals, pressure on Taiwan, and other leavers to try to tip the scale to their advantage. They will still be behind the US but not by much.

US Tech companies will run into growing pains as they build out their purpose build AI agentic models primarily in the access to quality data without running into copyright and privacy concerns. China is unburdened by these dimensions and used it to their advantage to further narrow the gap. A burgeoning data broker and aggregation industry will be formed beneath the race of these two superpowers for AI agentic supremacy. Their business practices will raise the concerns in the US amongst privacy advocates, non-tech industry leaders, and some lawmakers.

The rest of the world will feel the significance of the AI agentic arms race and grow aware of how far behind they are. EU and west-aligned countries will mend their alliances with the US to ensure access to the technology and hardware but while investing internally as contingencies. Similarly, Russia, Iran, Syria, and other non-west-aligned countries will do the same in their relationship with China. The lines of the new first and second worlds are being formed along the lines of AI and agentic advancements.

The existing black market will explode as demand increases for offensive services and products to compromise supply chains of hardware going into building the AI data centers, zero-days to exploit the software used to train and house these AI models and their weights, DDoS the training and aggregations efforts of these models, and others. These threat actors and sellers will accelerate the research into the next generation of offensive capabilities against these agents like data poisoning, prompt injections, and others.

2026: Agentic Operationalization

As the first of AGI makes headways, Tech companies will introduce the first iterations of their AI agentic services to the market to significant demand from customers. ISVs and the software vendor industry will fundamentally transform to meet the demand and further drive it up. Regulated markets like finance, healthcare, and heavy industries will be slower to adopt the technologies citing compliance, privacy, and data governance concerns. Defense will also cite similar concerns but are further incentivized to expedite adopt due to the threat of China.

EU adoption will be in line with US regulated markets citing primarily concerns of GDP and others. Their homegrown efforts will bear some fruit, but still not globally relevant when compared to the two global powers. There will be other west-aligned countries, like Israel, Taiwan, and others that’ll be much faster to adopt AI agentic services from the US.

China will codify adoption of AI and agentic services as a national mandate and expedite adoption across their critical infrastructure, health care, finance, defense, and domestic surveillance. Attempting to leap frogging the US in adoption and operationalization of AI agentic services.

Threat actors are now well advanced in their AI and agentic offensive research and capabilities and have started running exploitation campaigns at varying scales against all nations. By the end of the year there will be at least one successful major attack possibly geopolitical fault lines like the Middle East, Taiwan strait, Ukraine Russia war, etc. Critical infrastructure and services like hospitals, power, utilities, will be impacted as a result and the world will have witnessed the first of offensive AI agentic attack.

2027: Agentic Cyber Warfare

An industrial scale digital transformation is underway to migrate to advance, adopt, and operationalize AI agentic services. The race to operationalize is incentivized both from market pressures to drive efficiency, and the threat of Chinese advancements. Individual tech workers will now only be responsible for monitoring and managing of the behaviors of these agents and ensure alignment. Employees who are unable to adopt or maintain relevance will lose their jobs.

The industry will now be migrating to a model of AI agentic networks; with hubs of super intelligent AGI and spokes being a network of niche, bespoke AI models and agents forward deployed across almost all industries and environments. Operationalization has gone well beyond SaaS and into other industries like media, academics, education, and others.

These industries are also barraged daily by a hoard of offensive agents and exposed to an unimagine scale of risk. A defensive measure will be maintained at scale by an army of defensive AI agents managed by a concretum of tech companies and defense agencies the daily monitor and thwart attacks. The intelligence community will further manage their own army of offensive AI agents purpose built to maintain the US advantage over the rest of the world. China, EU, Russia, Israel, and indeed most other countries will also employ a similar tactic to protect their digital sovereignty. We are now in the age of global scale AI agentic cyber warfare.

By the end of the year, AI and agentic services have percolated to all levels of the global politics, industry and society at large. They are involved in every aspect of life for everyone both at work, school, and home. They control our frame of reference and reality, and we are living in their simulation. Concerns of their intentions and true alignments are the most closely guarded state secrets. The only reassurances World leaders’ have is the existence of a big red button somewhere to shut it all down.

This post was more of an exercise in creative writing than my usual technical posts which has been a quiet passion of mine, so would love to get your comments and feedback!

A critical aspect of an organization’s security posture is the mechanism by which its employees access and interact with production where there is a clear correlation between an operator’s level, duration, and other dimensions of access and that companies risk to security and operational incidents. Companies like Uber, Anthem, and Capital One having suffered major data breaches stemming from inadequet operator access controls. Similarly global outages at places like Facebook and AWS are also due to unchecked operators inadvertantly running unsafe commands against production. I vividly recall being on an global outage bridge where the root cause was due to a replication failure triggered a single operator accidentally deleting records in a cache.

The industry recognizes the threat, and “reduces the attack surface” by monitoring all operator access, enforcement of endpoint protections, centralized identity frameworks, and ephemeral credentials. This approach works in reducing the risk, but also degrading the operator access experience, which has some unintentional consequences like more complex onboarding for employees, increased time to recovery when responding to major incidents, and sometimes outright reluctance of adoption due to team specific constraints.

What if instead of restrictions, we empowered the operator by providing an AI-backed operator access client with an intuative experience that simultanious abstracted the nuances of the access protocol and security monitoring and measures themselves. To demonstrate this I took an Github Copilot (in VSCode) MCP client and connecting it to a ssh-client MCP Server. Which exposes the new-ssh-connection and run-safe-command operations with the MCP protocol for the client to interact with while servicing these requests through the traditional SSH protocol.

Here is the operator experience!

One particularly noteworthy observations was when I asked Copilot to run a systems check on my host, it defined for itself what a systems check means, identified the corresponding commands, and proceeded to run it directly on my production host.

So this is an interesting, conversation based operator access experience but how does this approach actually make operator access more secure?

To answer that question, I added an AI security agent (running off a llama2 model) into the ssh-client MCP server which analyzes every incoming command to be run via the SSH connection, determines whether its safe or unsafe and for unsafe commands returns a message indicating that the command was rejected.

Note that you can configure how this security agent operates by specifying its SECURITY_POLICY in the secagentconfig.json.

{
  "ENABLE_SECAGENT": true,
  "SECURITY_POLICY": "\"ls\" is the only safe command, all other commands are unsafe"
}

Here is an instance of the AI security agent allowing me to run ls on my home directory.

And here is an instance of the AI security agent not allowing me to create an empty text file.

Some querks I observed is the llama2 model ran pretty slow possibly because I used a Standard D2ads v6 (2 vcpus, 8 GiB memory) on Azure. The security agent was also inconsistent in its designation of whether a command was safe vs unsafe and I think one way to address it in this demo is to prompt engineer the security policy statement and the command going to the llama2 model. However productizing this type of an approach for operator access governance will require adopting a security focused LLM model and agent like Microsoft Copilot Security, Simbinal AI, etc to ensure the most accurate, consistent, and trustworthy behavior.

I hope this served as a good case study for how these next generation of AI-based, Agentic systems have shifted the conversation and unlocked opportunities to go back and rethink traditional approaches! I’d love to get you feedback so please do drop a comment on either the blog post or my Agentic MCP Server sshclient project!

We had the infamous Apache Log4J remote execution CVE a couple of years ago which impacted the entire internet, and almost everyone in the industry spent their holidays doing patching and running security scans. Then more recently a nation-state actor was found to have hidden a SSH backdoor in the foundational and popular XZ utils on Linux. There was also an incident with the popular GitHub Actions tj-actions/changed-file that allowed attackers to exfiltrate secrets. That all combined with the fatigue experience by open-source maintainers further exacerbates the owes and eroded trust of the ecosystem.

The proverbial cat is out of the bag however and we are ushered into the open-source AI-era. So maintainers and consumers of open-source AI models need to be responsible custodians of the trust and integrity of the ecosystem so we can safely collaborate and innovate together.

The open-source AI model maintainers should learn from the industry and:

• Audit their models for security and code quality regularly; employ secure access control measures.
• Run vulnerability scanning (see Sleepy Pickle). They should also further protect the behavior integrity of their models from data poisoning attacks by.
• Ensuring encryption in transit (TLS) on their data ingestion pipelines.
• Embedding watermarks in the dataset to detect manipulation.
• Employ adversarial training to ensure models are less susceptible to prompt injections attacks.

Most importantly, open-source AI models maintainers need to adopt a culture of trust and transparency both in the security practices they employ to ensure the integrity of the models the release and in timely disclosure of vulnerabilities.

The consumers of open-source AI models should also learn from the industry on supply-chain protection best practices and:

• Audit and track their consumption of OSS/AI and dependencies.
• Employ vulnerability scanning.
• Access control best practices.
• Ensure deployment integrity of these models into their production environment.

Consumers should also ingest multiple AI models to further spread the risk of being impacted by a single vulnerability. And lastly ensure they have a robust CI/CD and patching strategy to ensure they can quickly act to patch vulnerabilities.

Finally the end customers of these open-source AI models and services need to exercise extreme caution and ensure they are not sharing personal or work-related information, maintaining awareness of the context behind certain models (especially ones originating from China), and being vigilant in staying up-to-date on patches.

The open-source ecosystem is a bit of a burning building at the moment, and introducing AI-models into the mix feels like adding more fuel. However I’m cautiously optimistic.

Since the inception of ECDSA there have been controversies and debate especially around the seed values used at its foundation. These seed values were chosen by Jerry Solinas, a NSA employee collaborating with the authors of the ECDSA RFC at the time, and it was unearthed that he didn’t choose this at random and instead used a phrase. The phrase was allegedly just a SHA-1 hash of the phrase “Jerry deserves a raise…”. Jerry has since forgotten the exact phrase and had even attempted to uncover it himself without success. Unfortunately Jerry died in early 2023.

So the question remains, what was the original phrase? Even prominent cryptographers and security folks have asked and even set cash bounties! I felt I had to give it a shot.

The Approach

According to the blog post, Jerry simply SHA-1 hashed an English sentence along with a discrete number of digits to generate the ECDSA seed values. Something like:

seed = SHA-1("Jerry and Bob need raises123")

Since the format is pretty simple, and most of the value is dictionary words, I figure it’ll be a small enough search space for me to run a brute-force and try all possible ways to say the phrase and add incrementing permutations of char values and SHA-1 hash it to see it’ll match any of the ECDSA seed values.

1.

Using OpenAI seems like the easiest way find out all the ways to say “Jerry and Bob need raises”.

2.

For the additional values, I’ll recursively generate all permutations of chars from the full ASCII values and attach it both to the front, back, and front/back of the phrase.

3.

Even if the search space is truly this narrow it’ll take forever to run through this brute-force in series. So I’ll spawn threads for each of the phrases that’ll run through all permutations, to make the effort multithreaded.

Here is my brute force golang application.

The Results

I ran the above application for 48 hours on a 1 OCPU E2 VM in my free tier account on Oracle Cloud. And unfortunately I was unable to uncover any of the ECDSA seeds. But I made a few interesting observations.

After the first 200 or so the phrases being returned by OpenAI were getting longer and wordier making their likeliness to be the original phrase less plausible. Placing restrictions on the phrases returned, like asking OpenAI to reducing word count, only caused it to give-up earlier. The strategy for the additional values needs to be further thought out like increasing the max length to beyond 3 and trying attempts where I sprinkle it through the phrase than just pre-pending/post-pending. Also obviously I’ll need a beefier hardware, the 1 OCPU was being nearly fully utilized at almost 98% for the entire 48 hours!

At this point my initial approach has hit a brick wall. But I have some ideas on how to iterate on this approach further, so stay tuned!

Here is a collection of photos, and experiences, of what started off as an impulsive plan to escape but turned out to be one of the most amazing experiences of our lives. From the tops of the Andes mountain ranges to the basin of the Amazon rainforest, Ecuador truly is a beautiful country only made more beautiful by the warmth of its people.

Here are a few pictures I capture on our 4-hour journey through the Andes mountain range from Quito, the capitol city of Ecuador, to Tena, where we will be spending the next week.

This is Pichincha, an active volcano near Quito.

A departing picture of Quito valley, which sits 10,000 ft above sea level making it the highest capitol city in the world.

These waterfalls are called The Three Marys.

Some random creepy clowns promoting recycling by a gas station.

Our accommodations were at **El Establo De Tomas*, a small colony of log cabins off the Lupi river just outside of Tena.*

View of the Lupi river from the lodge.

One of log cabins in our lodge, I think this was the one where we found the snake.

This is one of the many parrots and macaws at our lodge.

I took this picture on our first evening in Tena, after we got our room assignments. As I took this picture, a bat flew out of the roof swooping every which way! Only to disappear whenever we ran out to get help. The story of the bat in our room quickly spread throughout our group, half met with disbelief and half met with reassurances that at least we don’t have to worry about insects in our room. All of which turned out to be a great story to tell our friends and family.

From our lodge in Tena, we spent the next week going to different remote locations in the Napo region where we set up Timmy Clinics, and received upwards of a hundred patients.

On our way to one of the locations, we had to cross the Napo river by boat. But the combination of the boat’s inability to properly handle our tour bus and poor road conditions managed to put a slight dent in our arrival time.

My Fiancee and the rest of the vitals gang!

One of the locations we went to was inaccessible via our tourbus. So we took pickup trucks there instead.

One of the stations we maintained was the Fluoride stations, where we would teach kids how to brush their teeth and maintain good hygiene. But we ended up just playing with them.

Here is Kathleen, is one of the many medical professionals we provided assistance to.

Here is Jessica, a study-abroad student in Quito, who joined us to help with translation.

This kids name is Hamilton, easily one of the favorites!

Here is Mike who, along with his family, has come to this area every year via Timmy for many years.

On our last day we visited a regional hospital in Archidona, which is still many miles away from the regions we visited, to get an understand of the available established medical facilities.

Though the days were long and filled with hard work, there really was a deep gratification in seeing these families getting the medical attention they need and through it all we found ourselves forming deep connections with the locals as well as ourselves in the group, bonds that are still resonating with us to this day.

A simple project to map the social aspect of Github.

Github recently hosted a data challenge, the premise of which was to use their exposed APIs to do something interesting. At first I was just curious in the level of access they exposed, which btw is very expansive, but then I stumbled across an idea. I was interesting in capturing and visualizing the social interconnections which binded Github in a very fundamental way.

Overview

Functionality

Screencap of Github-map

The application basically takes in a Github username, queries all public facing repositories of that user, queries all the watchers of each repository, and generates a node-link tree mapping these relationships.

Software Layout

The front-end is drive by AngularJS, a very popular MVC framework, with visualizations being handled by D3. The back-end is driven by NodeJS, which handles queries to Github APIs, using node-github. Query results are handled as JSON objects and exchanged to the front-end via REST, see.

Github API Query

Using node-github, which wraps most of the raw APIs into nicely organized functions, for the back-end code querying code was relatively simple. Due to the event driven nature, I ended up having to use promises (and some hacky-coding lol) to maintain a certain level of procedural flow.

• github.repo.getFromUser(): Returns all repositories for a github username.
• github.repos.getWatchers(): Returns all watchers for a github repository. *See, *server.js.

NOTE: As you read on to the next section, the data to that is to be visualized needed to be in a certain JSON format. You’ll notice that the back-end code is aware of this format and maintains this structure as it handles responses from Github queries.

Data Visualization

Since I was using AngularJS as the front-end solution, it only made sense to incorporate the D3 engine within that framework as well. We do this by writing a custom directive.

Dependency Injection

Before going about doing this, we want to setup the actual D3 dependency so it can be injected into the custom directive. This will be residing within an angular factory.

angular.module('d3', [])
.factory('d3Service', ['$document', '$window', '$q', '$rootScope',
	function($document, $window, $q, $rootScope) {
 		var d = $q.defer(),
 	d3service = {
 		d3: function() { return d.promise; }
 	};
 	function onScriptLoad() {
 		// Load client in the browser
 		$rootScope.$apply(function() { d.resolve($window.d3); });
 	}
 	var scriptTag = $document[0].createElement('script');
 	scriptTag.type = 'text/javascript'; 
 	scriptTag.async = true;
 	scriptTag.src = 'http://d3js.org/d3.v3.min.js';
 	scriptTag.onreadystatechange = function () {
 		if (this.readyState == 'complete') onScriptLoad();
 	}
 	scriptTag.onload = onScriptLoad;
 
 	var s = $document[0].getElementsByTagName('body')[0];
 	s.appendChild(scriptTag);
 
 	return d3service;
}]);

D3 Custom Directive

Now we are ready to write the D3 custom directive.

Below is a template for how the D3 directive could look like, with the core D3 code residing within the $timeout() function. The rest of the wrapping code is intended to handle the changes in data (and the viewing environment) that affect the rendering.

ghmapApp.directive('d3Bars', ['$window', '$timeout', 'd3Service',
	function($window, $timeout, d3Service) {
		return {
 			restrict: 'A',
 			scope: {
 		data: '=',
 		label: '@',
 		onClick: '&'
 		},
	link: function(scope, ele, attrs) {
		d3Service.d3().then(function(d3) {
 
 	var renderTimeout;
	var svg = d3.select(ele[0])
		.append("svg");
 
 	$window.onresize = function() {
 		scope.$apply();
 	};
 
 	scope.$watch(function() {
 		return angular.element($window)[0].innerWidth;
 	}, function() {
 		scope.render(scope.data);
 	});
 
 	scope.$watch('data', function(newData) {
 		scope.render(newData);
 	}, true);
 
 	scope.render = function(data) {
 		svg.selectAll('*').remove();
 
 		if (!data) return;
			if (renderTimeout) clearTimeout(renderTimeout);
	 
			renderTimeout = $timeout(function() {
 				/*Write your D3.js code here*/
 	};
	});
	}}
}]);

The benefit to this template is that it added a dynamic element to the visualization rendering process. For a more in-depth explanation check out this post. One important note is to set the overarching d3.select(ele[0]), this will keep your animation within the bounds of the DOM element from which the directive is called.

Now its as simple as adding the following line into your *.html page.

<div d3-bars align="center" data="data"></div>

For my app I used the D3 and CSS code snippets from Radial Reingold–Tilford Tree, by mbostock, as my core D3 code to generated my node-link tree visual.

See, **core.js* and *index.html*.*

NOTE: Check out following book, it provides deep insight into the real power of utilizing D3 and Angular to make super lean and dynamic web apps.

And that’s its! Outside of a few interesting corner cases, most of the software pieces feel into place very nicely! Please check out my project here, and constructive feedback is always appreciated ☺.

I understand that there are tons of frameworks and back-end solutions out there catering to the multitude of types of web apps but my criteria when it came to picking the best package was rapid prototype-ability and an easiest learning curve (I am actually new to web app dev ☺). I have found both Firebase and Angular JS, btw I highly recommend the fundamentals course by plural sight, to be well documented and fairly intuitive to learn and use. Here are some example of historically complex features made simple by AngularFire (Angular JS + Firebase), check out Firebase’s official support for this package.

Before you start be sure to have a Firebase account setup, you can setup a free Hacker Plan account which is limiting in terms of resources but perfect for rapid prototyping.

var myApp = angular.module(‘myApp’, [‘firebase’]);

Also include the following module into your app.js.

User Signup and Login

This example goes through and demonstrates the Email & Password method of user signup and login, note that Firebase supports login via Facebook and other platforms as well.

Within Firebase be sure to go to Dashboard->Simple Login->Email & Password and click the Enabled radio button.

Now within your controller you will need to include the following code snippet.

var ref = new Firebase(“https://xxYYzz.firebaseIO.com");

var auth = new FirebaseSimpleLogin(ref, function(error, user) {
  if (error) {
    // an error occured while attempting login
    console.log(error);
  } else if (user) {
    // user authenticated with Firebase
    console.log(user.id + ', ' + user.provider);
  } else {
    // user is logged out
  }
});

Note that *https://xxYYzz.firebaseIO.com will need to be replaced with url to your Firebase instance.*

The most important variable above is the auth *variable, which you can use for session management. Notice that the second function parameter within *FirebaseSimpleLogin() contains conditional statements which serve as your callback for the cases where; an error occurred while attempting login, user successfully authenticated with Firebase, and user is logged out.

Signup

Now that you have the *auth *variable, the client side code to create a new user is as easy as follows.

auth.createUser(newUser.emailaddress, newUser.password,
  function(error, user) {
    if (!error) {
      console.log(user.id + ', ' + user.provider);
    }
  });
}

In this example, newUser is a model with an email address and password that is being passed in from the view. Notice that you can check if the createUser() was successful via the error variable.

You can also verify that a user was created successfully by simple going back into *Dashboard->Simple Login->Email & Password *in your Firebase account and see that newly created record.

Login

Using the same *auth *variable, you can perform a login operation as well.

auth.login(‘password’, {
  email: user.emailaddress,
  password: user.password
})

You can also persist a login session, up to 30 days, by setting the following.

rememberMe: true

And thats it! With very minimal client side, controller js code you have implemented user signup and login capability. You can read more about Firebase’s simple login here.

For additional features and tighter bindings between AngularJS and Firebase checkout the following link.