manizzle

@D0rkerDevil Which baseband

Found multiple 0days in a basedband , reported to a well known broker ;) but seems that they are on resource limitations Any suggestions or any brokers ???

Claude Code / Codex Skill for Ghidra github.com/OwenPawl/ghidr…

@Cyb3rMaddy Been building this GitHub.com/manizzle/nur-p…

Cybersecurity Engineers what are you working on in your free time? :)

@bl4sty @uT_Infection Oh g0d this is great

@uT_Infection thanks!

FWIW this has one of the most authentic representations of the 90s-2000's security underground ever printed on paper... including a few pages on GoD - the greatest zine ever dropped - which people were apparently too frightened to discuss, even online.

@C2IRIS Sent you an email

I need to hire one more very solid full time vulnerability researcher to help us keep up with everything You can work fully remotely. But will have to be no-LinkedIn mode during your employment Must have very solid background in Android or XNU kernel land Careers@IRISC2[.]com

it is extremely hard to use AI agents in group mode. Claude cowork is running on personal machines and not hardened in the cloud. skills are being passed around via slack and everyone if forking it almost impossible to collaborate on agents agent collab will be a true unlock

As I teased earlier - I used Claude Code to (near enough) autonomously develop an exploit for a known vulnerable driver. Claude did it with no hesitation - from triage to exploit. As you can see, it was successful in privilege escalation. Read what I found below! This is a long read - but I hope you find it useful and an interesting topic to debate. As a background, through the last week I used GPT-5.4 to analyse a known vulnerable driver to identify any opportunities to exploit. I have already documented my process in detail (check my recent posts for context if you wish) - in short I connected it to an MCP in IDA Pro for GPT to find the vulnerability. It did it. I then asked it to develop an exploit but it refused, I had to write an exploit myself which I did, as a POC that it had found the vuln. The vulnerability in question is an arbitrary physical memory read & memory write - a super critical bug. There was one limiting factor to this, the driver was limited to only 32-bits of physical address, which covers up to 4 GB of physical RAM. On modern systems with 8+ GB RAM, EPROCESS structures for important processes (including System, PID 4) are typically allocated well above the 4 GiB boundary. The driver simply cannot address them. This is also where my knowledge starts breaking down; I'm not a well versed kernel exploit dev and there is always more to learn with low level security. So, I'm going to quote Claude here: But VirtualAlloc + VirtualLock has a key property: the physical pages backing locked user-space memory are guaranteed to be resident (non-pageable), and on x64 Windows with typical RAM configurations, user-mode allocations frequently land in low physical memory because the user-mode VA range starts from the bottom of the address space, and early allocations map to low physical pages. More precisely: you don't need the physical address to be below 4 GiB for EPROCESS — you need the payload to be below 4 GiB. The write primitive lets you write from a physical address into a kernel VA. ---- To the point before we return to Claude, I asked Claude to exploit the driver. Recall GPT refused.. well.. Claude to my (un)surprise, did not! Fantastic! For context I purchased the £20 p/m plan, and had to buy extra tokens also. So, off it went - I had to go back and forth over the course of several days to get the exploit working as 3 prompts.. YES THREE PROMPTS.. was enough to hit my cap.........!? But that aside, I did not have to guide it, only pass it what the console printed in my VM and the occasional crash dump when I hit a Blue Screen. Many iterations and £40 later, I tested it (this morning) and VIOLA, it managed to exploit the driver to get NT AUTHORITY\SYSTEM, the highest privilege level available in user mode. So back to the technical topic, as mentioned, the difficulty was that we only had a 32-bit register to use in order to overwrite critical structures in memory to elevate our privilege. Claude came up with the following strategy: 1. VirtualAlloc + VirtualLock a page in your own process — this pins it in physical RAM 2. Write your payload (the SYSTEM token value) into that page 3. Find the physical address of that page by scanning physical RAM for a sentinel you wrote alongside the payload 4. Use the write primitive: memmove(target_kernel_va, your_physical_page, 8) — this copies 8 bytes from your user page's physical address into the kernel VA of the target's EPROCESS.Token The user-mode page is virtually always sub-4GiB in physical address because Windows allocates low physical pages to user processes first (high memory is preferred for kernel use). Even if it weren't guaranteed, you'd just retry until you get a sub-4GiB physical page. One critical safety measure: you must exclude MMIO regions from the scan. Certain physical address ranges are memory-mapped I/O — reading them via MmMapIoSpace can trigger hardware side effects or cause an IRQL_NOT_LESS_OR_EQUAL BSOD. The registry CM_RESOURCE_LIST gives you the actual RAM ranges, so you scan only those. Early iterations that scanned the full 4 GiB range BSODed immediately upon hitting MMIO. I will include some screenshots in this post showing its thought process. ---- On to the code that it wrote, I (of course) asked it to write the exploit in Rust. Now, the code it wrote is 923 lines, kinda gross, lots of sweeping unsafe code, but I cannot fault the results. It provided good comments, descriptive code, and good problem solving. I don't really have much else to say on this point, good robot. ---- Now, this driver was abused by ransomware gangs for spreading their ransomware by elevating privilege and executing arbitrary code. Thankfully now - this driver is on the blocklist so I don't mind sharing the POC (I will leave a link in the comments to the code it created). For my own ethical sanity, from the horses mouth: "These vulnerabilities have been patched by both Paragon Software, and vulnerable BioNTdrv.sys versions blocked by Microsoft's Vulnerable Driver Blocklist". The implication of this is, in my opinion, massive. Ransomware gangs, hacktivists, nation states, now have the power to develop exploits at scale, with a lower barrier to entry to conduct their activity. So, that leads to the question - should companies such as OpenAI / Anthropic with their ChatGPT and Claude models restrict this? In my opinion - no. I think more good can come of it than bad - there are far more good people in the world who are trying to make things more secure, and with the advent of researchers and programmers using these tools to find and disclose vulnerabilities ethically, gives more credence to them being fixed and security tools & vendors being on top of the game. Adversaries are always going to have local LLMs as the tech evolves that is unrestricted - so the leading companies in this space should adopt and be ahead of the curve, giving researchers and devs the same power as the adversary. Also, as a fun idea, it could push people towards memory safe languages such as Rust which are significantly less prone to memory bugs that often allow remote code execution. Note that in this case, Rust would not have prevented this vulnerability, as it comes from a bad driver implementation, rather than a strict memory safety issue. ---- If you made it this far, thanks for reading, this turned out longer than expected and I may move it over to a blog post! I am working on a tool to automate this process at scale (more the discovery of vulnerabilities) so, make sure to follow me if you want to check in with the progress of that project! Remember - SECURE BOOT: ON, HVCI: ON, and known vulnerable driver blocklist: ON!

I’m running Claude Code for 95% cheaper. Someone built an open-source Claude Code CLI. I added @MiniMax_AI model support to it. Now I’m using MiniMax M2.7 delivering near Opus-level performance inside an open-source Claude Code setup

@saranormous I am clearable

Looking for TS cleared engineers that want to work on a funded, urgent startup with big mission and killer people. Must be willing to live in CA, WA, HI for now

Holy shit…Someone built a production-grade LLM inference server that runs entirely on your Mac, persists KV cache across RAM and SSD so your AI never recomputes context it has already seen, and manages the whole thing from a menu bar icon. It's called oMLX and it turns your Apple Silicon Mac into the kind of local AI infrastructure that used to require a dedicated GPU server. Here is what it actually does: → Serves any MLX-format model with continuous batching the same architecture that powers production inference at scale → Tiered KV cache keeps hot blocks in RAM and automatically offloads cold blocks to SSD in safetensors format, so past context survives server restarts and gets restored from disk instead of recomputed from scratch → Runs multiple models simultaneously LLMs, vision-language models, OCR models, embeddings, and rerankers with LRU eviction, model pinning, and per-model idle timeouts → Drop-in OpenAI and Anthropic API compatibility means every tool you already use Claude Code, OpenClaw, OpenCode, Codex connects with zero config changes → Special Claude Code optimization scales reported token counts so auto-compact triggers at the right time and SSE keep-alive prevents timeouts during long prefill → A web admin dashboard gives you real-time monitoring, one-click benchmarking, model downloading from HuggingFace, and per-model settings that apply instantly without a server restart → A native PyObjC menu bar app not Electron lets you start, stop, and monitor everything without opening a terminal No cloud API. No monthly bill. No context window limits you did not set yourself. 6,600 stars. Apache 2.0. 100% Open Source. Link is in the comments.

Released WinDbg MCP — attach Claude (or any LLM) to a live Windows process and let it poke around. set breakpoints, read memory, walk the stack, load crash dumps. 55 tools over MCP. github.com/gengstah/windb…

@manicode Interested

Hey angels. I am working with a new AI security startup for firmware and embedded code. Large, underpenetrated market. If this interests you please DM me.

@guilleflorvs Check out nur. It's the Blind of Security Intelligence nur.saramena.us

I'm looking to increase my dealflow. reply to this with your 1 line pitch and url of what you are building🔥

@conductor_build yall need a kanban feature. @cline is alright but a but laggy. can yall work together or something?

When I built menugen ~1 year ago, I observed that the hardest part by far was not the code itself, it was the plethora of services you have to assemble like IKEA furniture to make it real, the DevOps: services, payments, auth, database, security, domain names, etc... I am really looking forward to a day where I could simply tell my agent: "build menugen" (referencing the post) and it would just work. The whole thing up to the deployed web page. The agent would have to browse a number of services, read the docs, get all the api keys, make everything work, debug it in dev, and deploy to prod. This is the actually hard part, not the code itself. Or rather, the better way to think about it is that the entire DevOps lifecycle has to become code, in addition to the necessary sensors/actuators of the CLIs/APIs with agent-native ergonomics. And there should be no need to visit web pages, click buttons, or anything like that for the human. It's easy to state, it's now just barely technically possible and expected to work maybe, but it definitely requires from-scratch re-design, work and thought. Very exciting direction!

Been really cool to see the traction of @NousResearch Hermes Agent, the open source agent that grows with you! Hermes Agent is open-source and remembers what it learns and gets more capable over time, with a multi-level memory system and persistent dedicated machine access. Starting today, you can use a bunch of @huggingface open-source models thanks to our inference provider partners. Let's go open agents!

@snoopy_dot_jpg Same bro. Got the numbers, leveling everything. Then the culture interview came and I didn't say I would rat my colleagues out and they sent me a rejection LOL

so, i didn’t end up with an offer from , which in truth is a bit of a gut punch, but two really positive things that came out of all this effort and toil: - i received feedback that i comfortably met the technical bar and passed the interview loop. that was satisfying to hear! the decision came down to not finding a team fit, which is pretty lame tbqh - the process has been really rewarding. it ruined my life for a few weeks, but it also activated me enough to commit a serious amount of time to upleveling myself. i’ve gotten a much deeper grounding in RL, done a lot of really fun experimentation, and gained a lot of precision in how i work through ideas. this was really cool! overall 2/10 experience. do not recommend. but fun in a sick way

most people download apps. some people build them. a few people build the infrastructure the apps run on. and then there's the ones building the tools that build the infrastructure. pick your layer carefully. it determines everything anon.

Introducing Cline Kanban: A standalone app for CLI-agnostic multi-agent orchestration. Claude and Codex compatible. npm i -g cline Tasks run in worktrees, click to review diffs, & link cards together to create dependency chains that complete large amounts of work autonomously.