DeepL Api 设计中的欺骗战术 #50
Replies: 30 comments 44 replies
-
看了看 确实挺有意思。空格的地方应该是根据一些自动发json包去空格的特性来拦截一部分人,已经实现滥用了,谢谢博主。 |
Beta Was this translation helpful? Give feedback.
-
DeepL这种原本就是要提供免费功能的客户端,不太可能引入帐号等鉴权机制,DeepL为了让用户下载他的客户端,在里面安置了这样的绊子。 其实这些方法就是客户端与服务端之间的某种共识,刚刚我突然冒出一个非常简单的想法,就是服务端随机的问客户端 “客户端本身某位置的字节内容是什么”,这样用户就不得不保留客户端原文件了,即使是接口被滥用,滥用者也必须保留原客户端完整的文件,以供验证。 |
Beta Was this translation helpful? Give feedback.
-
挺有意思,辛苦了 |
Beta Was this translation helpful? Give feedback.
-
确实挺有意思,很强!👍 |
Beta Was this translation helpful? Give feedback.
-
DeepL.Rpc.TextTranslation.TextTranslationRules :) |
Beta Was this translation helpful? Give feedback.
-
真有意思,学习了✔ |
Beta Was this translation helpful? Give feedback.
-
有、意思的这个🤔 |
Beta Was this translation helpful? Give feedback.
-
不得不说,都是人才啊,让你以为你什么都懂,实际上暗藏杀机 |
Beta Was this translation helpful? Give feedback.
-
有意思,尝试用 Python 实现了一下,已经成功。 |
Beta Was this translation helpful? Give feedback.
-
那如果客户端用的不是c#或者加了混淆,那岂不是铁定掉坑里。看来技术的深处还是玩弄人心啊 |
Beta Was this translation helpful? Give feedback.
-
这也太六了。。。。学习了 |
Beta Was this translation helpful? Give feedback.
-
爆破鬼才。。。我去年就跪在空格上了,真的干到后面怀疑了一段时间人生😂 |
Beta Was this translation helpful? Give feedback.
-
这种做法完全无法对抗逆向,真要对抗还是得传统的非对称加密那套。。。 |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
师傅,请问为什么我在我的ipad上抓出来的请求的timestamp并不是icount(3)的整数倍呢? {
"jsonrpc": "2.0",
"method": "LMT_handle_texts",
"id": 3228780004,
"params": {
"texts": [
{
"text": "iii",
"requestAlternatives": 3
}
],
"splitting": "newlines",
"lang": {
"target_lang": "ZH"
},
"timestamp": 1649427263572,
"commonJobParams": {
"wasSpoken": false
}
}
} |
Beta Was this translation helpful? Give feedback.
-
大佬牛逼,我也来说说自己的经验。在TB上买过账号(是pro,我也不懂,是一种团队账号,不晓得大佬也是买的这种),然后模拟web调用接口,每1-2秒一次,但用了几个小时,最多十几个小时,账号就会被脱离团队也就是取消了pro权限不能用了。 |
Beta Was this translation helpful? Give feedback.
-
学长,贵校是那所985呀,今年考研!还不知道怎么选学校
…------------------ 原始邮件 ------------------
发件人: ***@***.***>;
发送时间: 2022年4月18日(星期一) 晚上8:26
收件人: ***@***.***>;
抄送: ***@***.***>; ***@***.***>;
主题: Re: [zu1k/blog] DeepL Api 设计中的欺骗战术 (Discussion #50)
这篇文章的一个核心观点就是不要被表面的意思给误导😜
代码里有写要加一
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
老哥 docker版怎么换代理ip |
Beta Was this translation helpful? Give feedback.
-
你好,从Copy Translator过来,请问是否可以通过settings.toml设置更改窗口颜色为系统默认主题色(白),同时记住上次弹出窗口位置。 功能性方面,仅希望是否可以增加右下角状态栏图标,快捷键外多一个选择,感谢 |
Beta Was this translation helpful? Give feedback.
-
大佬,现在这个策略还有效吗? 我按要求改写了时间戳和空格设置,但还是一直429…… |
Beta Was this translation helpful? Give feedback.
-
deepl-api-rs能不能补个macOS的构建QAQ |
Beta Was this translation helpful? Give feedback.
-
收到了 DeepL 的邮件,已经删除相关内容 To whom it may concern I am part of DeepL’s legal team which is responsible for all legal aspects at DeepL SE. We have noticed the article on your blog about the DeepL API, available here: https://zu1k.com/posts/thinking/deception-tactics-in-deepl-api-design/. The article contains instructions on how to bypass protections of the DeepL API in order to make unlimited use of the DeepL API. This is unacceptable and violates the Terms of Use of DeepL Translator (https://www.deepl.com/en/pro-license?tab=free), which states clearly that the use of internal APIs without written permission from DeepL SE is strictly prohibited. As we have not given any permission, we ask you to remove the article immediately. This also applies to the further distribution of your article e.g. via Twitter (see screenshot) - we request that you also remove this Twitter-post as well as similar posts immediately. We are interested in a quick and unbureaucratic solution to this matter. However, if you do not comply with our request, we will need to involve our Chinese law firm to handle this matter. Please confirm to me the removal of the article from your blog as well as removal of corresponding links. |
Beta Was this translation helpful? Give feedback.
-
之前,写客户端的时候,也是不想搞账号系统,和他的这个思路很像,用一个公开信息作为识别码,其实不考虑账号token,也有很多判断方法最简单就是客户端生成算法和服务端保持一致不一致就认为是伪造,这样适用于不需要根据账号来封禁和记录信息的系统。可惜这种做法看似高明,却需要客户端有一定的防逆向措施。如果只是抓包我不需要去防,毕竟怎么生成的算法他得不到也无法伪造。可惜如果算法源码被知道了,那就没有任何意义,相当于公开的api暴露,以及没有账号系统无法确认是谁只能通过ip禁用,但是谁还没有几个代理呢?这样就导致必须双向更新客户端服务端算法,同时对普通用户会造成无法使用旧版的情况,而且能逆向一次还能第二次 最关键就是保护源码,混淆加密等等。所以只要能不被逆向 想怎么混淆api都能万无一失。 |
Beta Was this translation helpful? Give feedback.
-
DeepL Api 设计中的欺骗战术
在分析 DeepL 的接口时,我遇到了难以克服的困难,在对其客户端分析之后,我发现了 DeepL 的接口竟然有不可告人的秘密。本文解析 DeepL 接口防滥用之欺骗战术。
https://zu1k.com/posts/thinking/deception-tactics-in-deepl-api-design/#giscus
Beta Was this translation helpful? Give feedback.
All reactions