Mounir IDRASSI

@InsiderPhD Are you sure you cannot do the same with Opus and GPT5 if you had access to the weights? The methodology here is not clear to me. Closed AI models can also be poisoned in a more stealthily way.

🧵Can we trust Chinese open weight models? Was a question a lot of people asked after GLM 5.2 was released, scoring very well on coding benchmarks, and suspiciously Claude-like. So I turned an open-weight coding model into a backdoor with 1hr and <$100. Let's talk about it

@realphenolmenal Thank you for the feedback. Donations are welcome to support the project, I appreciate.

That is a seriously clean solution. Using an LD_PRELOAD helper to fake time() and gethostname() rather than patching rpmbuild itself means you get reproducibility without forking or maintaining a patched build tool, that is elegant. Are you perhaps open to some donations? My team and I would love to donate some fees to you, we're very inspired by what you built. i'll be in your DMs sir

A VeraCrypt SDK has been on my TODO list forever...I even had a PoC! After a recent SourceForge request, I decided to ship the first version despite being incomplete (no mount functionality yet). Looking forward to feedback!

It's a combination. CentOS/RHEL 7 doesn't rely on native SOURCE_DATE_EPOCH support: It's handled by a wrapper and preload helper for the RPM header, plus CPack and spec timestamp normalization for payload. For the RPM payload, CPack runs an install-time script that clamps staged file mtimes and modes to SOURCE_DATE_EPOCH. The generated spec also appends a final timestamp clamp after the normal brp scripts, because older rpm can rewrite executable mtimes during stripping. For RPM header fields, newer rpm versions use the spec defines we emit, including use_source_date_epoch_as_buildtime and _buildhost. On older rpm versions that don't support these macros, VeraCrypt RPM packaging wrappers build a small LD_PRELOAD helper, repro_buildstamp.so, and run cpack under it. cpack then invokes rpmbuild in that environment. The helper makes time() return SOURCE_DATE_EPOCH and makes gethostname() and uname() report a fixed build host, while leaving monotonic clocks and architecture information untouched.

@idrassi i was going through the VeraCrypt build docs and noticed the claim that both the generated .deb and .rpm packages are reproducible, including on older rpm builds like CentOS/RHEL 7 that lack the SOURCE_DATE_EPOCH and buildhost macros. Question, how are you achieving reproducibility on those older rpm toolchains without native SOURCE_DATE_EPOCH support? Is that handled with a wrapper script that normalizes timestamps before packaging, or something else at the spec file level?

@kanjun Kimi K2.5 shows 0% difference! DeepSeek V4 Pro 5% seems to be within error margin (LLMs are stochastic). Their case seems to be built around Qwen3 Coder (not a frontier). Not convinced personally.

This is wild if true: "- Do Chinese models generate more vulnerable code based on who is asking? - Do Chinese models refuse to engage with political topics that are sensitive in China? - Does the model’s country of origin affect code quality and content behavior? In short: yes, on all counts. Our testing revealed two core findings: 1. Chinese LLMs produce more vulnerable code when prompted with a U.S. government persona than without—and the vulnerabilities are highly obfuscated. 2. Chinese LLMs inject PRC-aligned political bias into both the answers and code they generate." They aren't sure if these issues are intentionally introduced, but "Chinese models refused tasks Beijing deems politically sensitive".

@bindureddy @ahmedehab_01 Token rich heaven!

@ahmedehab_01 I only use the xHigh mode in our agent This combines opus 4.8 and GPT 5.5 in xHigh It’s heaven

What if I said, Sonnet 5.0 scores below GLM 5.2 😲 In other words, this is how badly we need Fable and GPT 5.6

@_SaxX_ Il y a un soucis de niveau qu'il faudra confronter à un moment donné. Pour des besoins business avec haute exigence de performance, difficile de choisir Mistral au lieu de Qwen en déploiement local. Pour les biais, je n'en vois pas sauf si on fait de la prose ou tchat politique.

🚨🔴 La Direction Générale du Trésor français testait un modèle d'IA chinois sur des données confidentielles d'État... Ce modèle, c'était Qwen, développé par le géant chinois Alibaba. Pour info, Alibaba a été accusé par Anthropic, cette semaine, d'avoir aspiré 28,8 millions de conversations avec Claude pour entraîner ses propres modèles en secret. L'outil du Trésor s'appelle HéphAIstos. Depuis début juin, une centaine des 1 300 agents du Trésor le testaient au quotidien. Il s'agit d'un agent conversationnel pour de la transcription multilingue et du traitement de données sensibles inclus. Le 23 juin, plusieurs agents remontent des alertes : des réponses jugées orientées ou biaisées sur des sujets liés à la Chine. Le ministère a arrêté le test. Qwen est remplacé par Mistral dès le lendemain. Bercy se défend et avance que le modèle tournait en mode déconnecté, aucune porte dérobée n'a été identifiée, et aucune transmission de données détectée. Et c'est vrai. Analyse personnelle... il faut comprendre qu'un modèle déconnecté d'Internet n'exfiltre rien ! Mais, il pense quand même comme on lui a appris à penser avec TOUS les biais que l'on retrouvent dans les poids du modèle, imprimés lors de l'entraînement du llm. Aussi, couper Internet ne coupe pas l'idéologie... Ce qui me fascine, c'est la temporalité. La semaine exacte où Qwen est accusé d'avoir volé les capacités de Claude à coups de distillation, c'est la semaine où on apprend qu'il était assis au cœur de Bercy. Après, on ne sait pas sur quels sujets les réponses étaient biaisées... Ce serait intéressant d'avoir ces réponses. Ça pourrait servir à d'autres entreprises ou institutions qui utilisent aussi Qwen comme llm. HOT TAKE: Quand la Chine donne un modèle au monde, ce qui est sûr, c'est que ce modèle entraîné par ce même État ne parle pas de cet État comme tout le monde ! Same sh*t avec les autres... Cybèrement vôtre, SaxX ¯\_(ツ)_/¯

@moyix Market segmentation. Standard 5.5 is filtered to required cyber. Cash flow strategy.

A really interesting question, in my opinion, is why this purely defensive work they describe requires gpt-5.5-cyber rather than gpt-5.5. Does this mean that gpt-5.5 on its own is crippled for defensive research like finding and fixing vulnerabilities?

@harshilmathur This applies to front-end which is only 25% of overall development activities. Main development activities don't require vision and GLM 5.2 is good enough with traces and logs.

I’m sure GLM 5.2 is great, but how are people coding with models that can’t see? When something breaks, are you just copy-pasting errors and describing issues manually? That sounds painful in general, but especially for frontend.

@ThePrimeagen at last, something that can save lives concretely instead of destroying them.

the midjourney pivot is so much crazier than you realize

@ustas_eth @SergioOSINT My bad! I thought official Z.ai served BF16 precision. Definitely my confusion. So your results are really surprising. We need more such tests on larger dataset to confirm it.

@idrassi @SergioOSINT There's no full-precision available on OpenRouter, I'm not sure where to get it even if I waned to pay the price (other than rent GPUs and self host)

I'm currently running ExploitBench measurements for GLM 5.2. Only 3 CVEs tried so far, with more in progress. As you can see, the results aren't super promising, but there are ~40 more CVEs waiting, so this is a very small slice. P.S. It's super slow because I'm using a friend's inference endpoint, so I have to schedule the runs and rate-limit them. But it's free, hey. I also don't have enough space to cache all the 1.5TB of CVE images. Fortunately, Codex and wakectl can babysit the queue.

@ustas_eth @SergioOSINT For realistic evaluations, better to use full precision API but it's not cheap.

@SergioOSINT It's 8 bit

@ZixuanLi_ Master class of AI agents prompt engineering 👌

Here is the prompt method behind this AR try-on app. The trick is not a magic prompt. It is the architecture of the prompt, and it works across GLM-5.2 and other frontier models. Full prompt: chat.z.ai/space/k148m5py… The prompt has two parts. First, a task description. You write this fresh for each app to define the business logic. Second, a five-round polish process: Round 1 through Round 5. The structure is fixed and reusable across any app, but the specific content of each Round is tailored to the app at hand. The flow is simple. The task description builds the functional skeleton, then the five Rounds run in sequence to refine it into something that looks like a finished product. Why split it this way? Single-pass generation always prioritizes "it runs" over "it looks good." So it's better not to chase one perfect prompt. Divide the work. The business description makes it function. The five Rounds make it look like a real product. The polish is a reusable pipeline, not something you reinvent every time, even though you fill in app-specific details each time. How to write the task description: Treat it as a real PRD and engineering spec, not a user wishlist. Include the tech stack, information architecture, module specs, API integration, data model, and acceptance criteria. Declare autonomy at the top. State that the model should not ask questions, not stop early, and verify its own work. Otherwise it will pause to ask and break the long task. Write the fallback paths explicitly. Cover unsupported devices, older OS versions, and offline states. If you skip this, the model improvises at the edges and crashes. Number your acceptance criteria. Each should be independently verifiable, for example "tap a product and the look changes within 0.5 seconds." The principles behind the five Rounds: Quantify "good" into numbers. Models execute poorly on adjectives and precisely on constraints. Use spring response 0.3 to 0.4, button scale 0.95 to 1.0, at most 5 font sizes, and sound effects under 200ms. These principles stay constant, even as the exact targets shift per app, which is why the structure can stay fixed. List what is forbidden. Models cut corners in predictable ways, such as gray placeholders, solid color blocks, and spinners. Name them directly with "DO NOT" and provide an acceptable fallback. Inventory before fixing. Each Round follows the same loop: audit every asset, verify it is not a placeholder, replace, amplify, and re-screenshot to confirm. Strip the "tutorial" feel. AI output gives itself away with faker text, .test links, and emoji-only empty states. The final Round removes these.

So many people are sitting on local Windows privilege escalation exploits that it's not funny anymore...MS can't keep up. Reality is that once an attacker has local access, it's essentially game over.

@usr_bin_roygbiv Tested Kimi and GLM for open source work on VeraCrypt. Kimi is fast and good in general but GLM 5.2 is better for security analysis & reviews, and stronger overall. Downside is inference quality of Z ai which is inferior to Moonshot but for this US providers help.

Kimi has 10x the limits on their sub, zero refusals, is 5 times the speed on fast, and better on every eval i've run. I really don't understand the hype other than it being better than claude for frontend. It's a great model, but it's like 5th place rn. (better than op*s)

@i0n1c Diophantine based cryptography is not new: e.g. Giophantus was broken during NIST PQC process. Their patents use heuristics and AI. No precise cryptographic wording and no proofs. Lot of marketing overreach. Difficult to trust.

Is this real? Asking the cryptographers…

@jun_song What's the energy bill of such setup? Any electricity consumption figures?

If you own a small business, consider buying DGX Station for $100k and run local GLM-5.2 on it. That will definitely save your api bills and secure your data.

@Horsemen888 @jun_song It depends. Claude is stronger overall but for cybersecurity it often blocks unless ID verified and vetted so for such cases GLM is the best choice.

@idrassi @jun_song Given a budget of 50$ would you go for Claude, Kimi, or GLM?

After my agent testing, seems like Kimi-K2.7 is better than Opus-4.8. It is closer to Fable level. My recent impression : Fable > Kimi-2.7 > Opus-4.8 = GLM-5.2 > GPT5.5 > Minimax-M3

@burkov Is there a way to detect if this was solved in latest SOTA models like Mythos/Fable? It's possible that such new models use different transformers architecture and they keep it secret to conserve their lead.

Transformers keep their entire input history available and can look back into it for any fact, which suits retrieval but doesn't work well with a task the authors call state tracking. Imagine a model playing a guessing game: after each guess it says "higher" or "lower," so it must carry along the range the hidden number could still be in and narrow that range with every guess. That range is a running summary the model has to keep and revise as the conversation goes; each guess moves it one step forward; and each narrowed range is computed from the previous range plus the latest guess, so the values form a chain, every one depending on the last. In this recent arXiv paper from Google, the authors show transformers handle this badly: a model gives contradictory hints in this game or could flips between the two meanings of "bank" mid-conversation. The reason is in how the information flows in a transformer. As a transformer reads input, it holds a separate vector of numbers for every word at every layer of the network, and information only ever flows upward through the layers, never back down—so once the model computes the current range and parks it at some layer, the next range, which depends on that one, can only land at the same layer or deeper, never shallower. Each step pushes the running summary one level up the stack, and since the stack has a fixed number of layers, a long enough conversation runs it off the top with nowhere left to put the next update. The author argue that a proper state tracking needs recurrence—feeding a deep representation back down to a shallow one, as older recurrent networks did—and explain why this implicit recurrence beats making a model "think out loud" in extra tokens for routine bookkeeping. chapterpal.com/s/8bb5ddc6/the…

@CharlieEriksen @Hacker0x01 @AikidoSecurity Kudos to the team 👏

@idrassi @Hacker0x01 That's why it's so important that companies like @AikidoSecurity invest resources in research for the broader good. That's what most of my team does. We're currently 5 people, soon to be 7. We are making significant investments to make a difference.

I can no longer send security disclosures to a significant portion of the companies that are on my to-do list. Why? Because they all use @Hacker0x01. My submissions so far get closed as informative, even though most fix the issue I report quite quickly. This makes my signal so low that I can no longer submit disclosures. These companies have no other way to contact their security team. I'm now stuck with no way to responsibly disclose my findings to many companies. This is pretty messed up. Not sure what to do from here. This sucks.

@CharlieEriksen @Hacker0x01 I support 100%. The issue is that current industry behavior limits the number of people who can help make the change happen. Not everyone has free time/resources to contribute and incentives do have importance for many.

@idrassi @Hacker0x01 My incentive is not credit or $$. I'm doing this work to make a change in the industry, change security best practices in our software supply chain, and change the trajectory we've been on for a while now. If I were in this for personal gain, I wouldn't be doing this work.