Absolutely everything on this blog pertaining to the term “hacking” is meant for training and educational purposes only. WE DO NOT ENGAGE IN NOR PROMOTE ANY ILLEGAL HACKING ACTIVITY!

Before we dive deep into today’s post, let me take a second to tell you what we’ve been building behind the scenes…

We’re working on something that sits at the intersection of inner alchemy and intelligent design. We’re working on a tool forged not just in code, but built with the breath, posture, and presence in mind.

It’s called ChifuAI.

ChifuAI is an AI-powered application designed specifically for internal martial artists, especially those walking the paths of Qi Gong and Tai Chi.

And by no means will this be another fitness tracker or meditation gimmick. This is a Shifu in your pocket. If one could imagine.

A guide that reads your Chi Journal like a seasoned doctor reviewing an ancient scroll.

It takes your entries, whether typed in manually or streamed through your wearables, and gives you real, grounded feedback.

From breathwork to posture, from dietary recommendations to curated sequences, ChifuAI responds with wisdom modeled after real masters.

Upload a video of your form? It’ll tell you if your elbow’s floating too high or if your root needs to dig deeper. Choose your lineage? You can train in the style of a real human Shifu who’s contributed their knowledge to the platform.

And under the hood? APIs and machine learning quietly doing their thing- but as far as the user’s concerned, it’s just you and your practice, getting more aligned each time you show up.

This is what they mean when they say Grey Hat Developer is becoming Grey Hat Dragon. Because we’re not just hacking systems, we’re hacking wellness.

Not just breaking into networks, but unlocking flow, coherence, and vitality.

So here you have it.

Wellness, biohacking, chi metrics, internal mastery… it’s not just part of our services now.

It is the service. It’s the movement.

If this sounds like something you’d like to build with, breathe with, or shape with…

Welcome to the Sangha.

Let’s work!

This project couldn’t have fell in our laps at a more a perfect time.

Considering the advancement of AI and LLMs over the last year and the role that APIs currently have and have will in the future, researching the vulnerabilities around both of these topics becomes our immediate task.  

As for what this means operationally for us at Grey Hat Developer, well, it’s “Back to our regularly scheduled program.”

Which includes:

The grinding inside of TCM Academy on hacking APIs that we had to pause due to other contractual obligations that arose a little more than a year or so ago, among other things. 

And, although more recently added to the line up, we’ll most certainly be taking a look at the resources that are offered over at APIsec University. 

Speaking of which, if you absolutely don’t feel like reading at the moment but wouldn’t mind watching a video, drop in and have a listen to the awesome presenters over at APISEC|CON 2025.

When you’re done there, if you now consider how it all would relate to an application such as the proposed, “ChifuAI”, I’m sure you’ll have a better idea of our current project here at Grey Hat Dev.

So enough with the rambling and in true fashion of this blog, we’ll start with our customary walk-throughs which, if nothing else, serve as Proof Of Concepts of us documenting our “hands-on-deck” just in time learning method.

If you bang against production systems
dude, you’re off your rocker
So it’s proper,
that we install our tools inside of Docker. 

If not tha,
Net Daddy or Sys Addy
won’t be happy….
Exactly,
Let that be….
the reason we’ll hack CrAPI. 

You’ll see when we hack CrAPI
that it
wasn’t built for factory
So it won’t make no difference
how disruptive our attacks be. 

In fact see, it’s real
and just to prove this isn’t jive….
If you can’t run in Docker
no fret,
you can hack this live.

Before we start unpacking BOLA vulnerabilities, we gotta clear something up because folks tend to use these two terms like they’re twins when in reality, they’re more like cousins raised on opposite sides of town.

Authentication is who you are.
It’s your identity.
It’s the moment the system says:
“Alright, you say you’re Q. Show me the credentials.”

It’s your fingerprint. Your password. Your face scan.
It’s that digital handshake where the system nods and says:
“Okay, you’re in.”

But just ‘cause you’re in the building doesn’t mean you got keys to every room.

Authorization is what you’re allowed to do.
It’s access control. It’s permission.
It’s the system saying:
“Sure, you’re Q — but are you Q from HR or Q from Engineering?”

In the course, Alex used the analogy of a hotel.

You walk up to the front desk. They ask for your ID. Maybe a credit card.

They match your name to a reservation and hand you a key card.

That whole exchange? That’s authentication.

You proved who you were. You verified your identity.

But on the other hand, that key card they gave you doesn’t get you into every room in the building.

That penthouse suite on the top floor? Forgot about it, partner, you’re not getting into the penthouse suite unless you paid for it.

Also, you’re not accessing the server room unless your name’s on the clipboard. (Huuuuuge Red Flag by the way.) 

Maybe, if the card is working or if you don’t set your card near your phone before you try using it, you get access to the gym, the pool, your floor, your room… but that’s it.

That’s authorization.

See the difference?

So, the first thing we’ll do in our demo is create an account and log in. Which we do and as you can see, we get no vehicles found.

When we check our account in Mailhog, we can retrieve our VIN registration number and our PIN.

If we switch over to our proxy, on our left we have our Request where you can see what we sent over. What’s interesting is the url that’s included in the Response.

Notice the report_id=7 parameter in the endpoint returned in our Request. This is the object id assigned to our JWT (JSON Web Token) in our Request.

Next we’ll send another request under our JWT but let’s change the report_id parameter to something other than the one assigned to us, which is 7. Let’s say, 5. 

As you can see, we’ve just obtained access to information that we were not supposed to be privy to. In this case, PII (Personal Idenifible Information) and some other info that could be chained together and used later down the road, increasing the severity and impact of the vulnerability. 

Again, if we change that id parameter we find that we’re privy to more information. Let’s say, 3.

When Identity Ain’t Enough

So let’s recap what we just unpacked:

Authentication is who you are.

Authorization is what you’re allowed to do.

BOLA – Broken Object Level Authorization – is what happens when systems forget to check that second part.

We walked through a real example using crAPI where an authenticated user was able to bypass security by simply changing an ID in a URL, and accessing PII information they weren’t authorized to.

So, in a world where APIs are the bloodstream of AI systems – especially ones like the proposed ChifuAI, where health data, journal entries, and video uploads are flowing between users and devices – a BOLA vulnerability isn’t just a bug… it’s a breach of trust.

Imagine someone slipping into a sacred space that was only meant for you – your breath-work logs, your energy scores, your movement history. That’s what happens when authorization is ignored.

Hack On, Ladz & Gentz!

If this post made you pause…
If it helped you see the layers beneath your login screen…
If you’re building apps, or just trying to breathe a little deeper in this digital storm…

Then join our Sangha.

The Chifu Dharma Newsletter is where tech meets tranquility.