分类：安全文库

挖洞经验 | 利用XSS和CSRF漏洞远程实现PayPal合作方网站未授权账户访问
继上次发现PayPal远程代码执行漏洞之后，我又通过CSRF和XSS方式发现了PayPal合作方网站的未授权账户访问漏洞，利用该漏洞可以远程窃取用户账户Cookie信息，实现账户劫持。

前言

在想办法绕过WAFs，或希望通过存储型XSS构造远程XSS攻击时，XSS漏洞的挖掘就派上了用场。在这有三个经典粟子大家可以仔细研究学习：

whitton : uber-turning-self-xss-into-good-xss

geekboy：airbnb-bug-bounty-turning-self-xss-into-good-xss-2

arbazhussain：self-xss-to-good-xss-clickjacking-6db43b44777e

如果你能发现某个WEB应用的存储型XSS漏洞，并且其对CSRF（跨站请求伪造）无任何防护措施时，那么，恭喜你，你挖到宝藏了！

开始

我有幸就发现了这么一个网站，PayPal合作方网站 https://www.paypal-brandcentral.com/，其中用来表示集合名称”Collection Name”的参数”name”，存在XSS漏洞，之后，经验证该网站没有采取任何CSRF攻击的防护措施。这就存在可利用之处了。

为了形成CSRF攻击，攻击者通过构建形如以下的恶意XSS Payload，发送至用户端，一旦用户点击该Payload框架中的链接，将会自动创建一个新的集合名称，同时执行窃取Cookie的操作或其它跳转，实现攻击者恶意目的。由于未采取任何CSRF攻击防护，攻击者可以利用该方法间接访问控制用户账户。
```
<html>   <body>     <form action="https://www.paypal-brandcentral.com/!/Lightbox/createNode/" method="POST">       <input type="hidden" name="name" value="&quot;&gt;&lt;&#47;title&gt;&quot;&gt;&lt;svg&#47;onload&#61;prompt&#40;document&#46;cookie&#41;&#59;&gt;" />       <input type="hidden" name="itemId" value="0" />       <input type="hidden" name="itemType" value="" />       <input type="hidden" name="guid" value="" />       <input type="submit" value="Submit request" />     </form>   </body> </html>
```
结束

就是这么简单，一些大型网站或周边应用一样会存在我们根本无法想像的漏洞，只是需要大家细心去发现。当然，这并不全靠运气，还得认真打好基本功才行。

*参考来源：pentestbegins，1024rd小编clouds编译，转载请注明来自1024rd.COM
2017 年 9 月 7 日
这些海报设计中的文字用的太妙了…

封面设计：∆ Studio—JQ ∆

居西雅图的女设计师Bethany Heck的字体设计十分抢眼，客户包含《纽约客》《Smashing Magazine》等多个国际级别的刊物。

2017 年 9 月 7 日
挖洞经验 | 记一次针对Twitter（Periscope）API 的有趣挖洞经历
近期，我在Twitter的Periscope服务中发现了一个漏洞。这是一个CSRF（跨站请求伪造）漏洞，虽然这个漏洞并不算是高危漏洞，但是发现该漏洞的整个过程我认为是非常值得跟大家分享的。

就在几天之前，我发现Twitter发布了一个名叫ProducerAPI的接口，该接口目前仅提供给Twitter的合作伙伴使用，Twitter的第三方合作伙伴可以在特定的应用（例如外部相机设备）中利用该API与Periscope账号同步流媒体视频。

注：在此之前，Periscope曾是一家流媒体直播服务运营商。广大用户不仅可以通过Periscope与其他人进行视频直播，而且还可以分享视频或进行评论。Twitter在2015年3月份以接近亿美金的架构收购了Periscope，并将其融入了自己现有的社交平台服务中。

这样看来，Twitter应该在这里需要使用到一些与OAuth相关的东西，而就我过去所积累的经验来看，OAuth的实现过程中一般都会存在安全问题，因此我决定要深入分析一下这个API接口。

在分析过程中，我遇到的第一个问题就是Twitter似乎并没有提供Periscope API的开发文档。不过Twitter在一篇官方博客中列举出了能够使用这个API的第三方厂商，所以我感觉可以看看这些厂家是怎样跟这个API交互的，然后也许还能从中找出一些端倪。但不幸的是，大多数的这些厂商或服务都需要订阅之后才能使用Periscope的功能，即便是我愿意为服务付费也没用。

不过我后来发现有一个移动端应用程序（Mevo for iOS）也在使用这个API。在这个移动应用中，OAuth请求都是直接从客户端发送的，这样我们就有可能通过拦截并分析网络流量来了解API的调用情况了。与OAuth 1.0a不同的是（OAuth 1.0a使用了签名来隐藏类似consume_secret这样的重要信息，并防止流量被拦截），OAuth 2.0会通过HTTPS来发送所有流量。因此，除非应用程序使用了某种安全系数非常高的证书机制（可以使用SSL Kill Switch2来解决），否则这些还是难不倒我们的。

我遇到的第二个问题是，为了使用这个App，我首先得要有一个Mevo摄像头才行…在亚马逊上逛了一圈之后，最便宜的Mevo摄像头要399.99美金，穷哭在厕所的我当然不会为了测试而去买这么贵的东西了，而且这里还不一定存在漏洞。

于是乎，我决定通过另一种方法来进行测试，即逆向工程分析。首先，我需要一台已越狱的iPhone和Clutch来解密IPA文件，然后用class-dump来生成Objective-C头文件，最后再用Hopper来对代码进行反汇编。

一开始我尝试在头文件中搜索字符串“Periscope”，因为那些负责处理Periscope交互逻辑的类很有可能会包含这个字符串。

搜索之后，这些类似PeriscopeBroadcastCreateOperation.h或PeriscopeBroadcastPublishAPIOperation.h的文件名吸引了我的注意，因为这些头文件看起来似乎与Periscope API的调用有关。通过对这些文件进行分析之后，我发现它们都继承了PeriscopeAPIOperation类，所以接下来我就要重点分析这个PeriscopeAPIOperation类了。

PeriscopeAPIOperation类的代码如下所示：
```
// 
// Generated by class-dump 3.5 (64 bit). 
// 
// class-dump is Copyright (C) 1997-1998,2000-2001, 2004-2013 by Steve Nygard. 
// 
 
#import "GroupOperation.h" 
 
@class NSDictionary, NSMutableURLRequest, 
PeriscopeOAuthOperation, 
PeriscopeRefreshTokenAPIOperation, 
URLSessionTaskOperation; 
 
@interface PeriscopeAPIOperation : 
GroupOperation 
{
NSDictionary *_JSON;
URLSessionTaskOperation *_taskOperation;
PeriscopeRefreshTokenAPIOperation *_refreshTokenOperation;
PeriscopeOAuthOperation *_oauthOperation; 
NSMutableURLRequest *_request;
}
 
+ (void)removeCookies; 
+ (void)logout; 
+ (id)userID; 
+ (id)refreshToken; 
+ (id)accessToken; 
+ (void)updateAccessToken:(id)arg1; 
+ (void)setAccessToken:(id)arg1refreshToken:(id)arg2 forAccount:(id)arg3; 
+ (_Bool)isUserAuthorized; 
+ (id)buildRequestForPath:(id)arg1params:(id)arg2 query:(id)arg3 queryItems:(id)arg4 HTTPMethod:(id)arg5accessToken:(id)arg6; 
 
@property(retain, nonatomic)NSMutableURLRequest *request; // @synthesize request=_request; 
@property(retain, nonatomic)PeriscopeOAuthOperation *oauthOperation; // @synthesizeoauthOperation=_oauthOperation; 
@property(retain, nonatomic)PeriscopeRefreshTokenAPIOperation *refreshTokenOperation; // @synthesizerefreshTokenOperation=_refreshTokenOperation; 
@property(retain, nonatomic)URLSessionTaskOperation *taskOperation; // @synthesizetaskOperation=_taskOperation; 
@property(retain) NSDictionary *JSON; //@synthesize JSON=_JSON; 
 
- (void).cxx_destruct; 
- (void)repeatOperation; 
- (_Bool)operationHas401Code; 
- (_Bool)shouldHandle401Code; 
- (void)operationDidFinish:(id)arg1withErrors:(id)arg2; 
- (void)finishWithError:(id)arg1; 
- (id)initWitMethod:(id)arg1params:(id)arg2; 
- (id)initWitMethod:(id)arg1params:(id)arg2 HTTPMethod:(id)arg3; 
- (id)initWitMethod:(id)arg1queryItems:(id)arg2; 
- (id)initWitMethod:(id)arg1params:(id)arg2 HTTPMethod:(id)arg3 queryItems:(id)arg4; 
 
@end
```
大家可以从上面这段代码中看到，其中包含了很多很多的属性和
方法。从这些方法名中可以看出，这个类应该就是负责处理Periscope API调用的类了。

接下来，我打开了Hopper来验证我的想法。果然没错，这些方法都会调用initWitMethod并通过传递各种参数来实现API的初始化。

这样一来，我只需要找出其他调用了这个方法的地方，我就能够列出所有的Periscope API调用以及相关的参数名。通过对相关类进行深入分析之后，我还可以从静态字符串中提取出Mevo的API root、clinet_id以及client_secret了。

接下来，我们就可以检查Periscope的OAuth实现中的漏洞了，而Periscope初始的身份认证节点并没有部署CSRF保护机制。如果一个第三方应用可以请求获取用户Periscope账号信息的完整权限，那么攻击者就有可能创建一个恶意第三方应用来伪装成用户执行恶意操作了。

总结

1.从今以后，我都会时刻关注Twitter的更新情况，并在第一时间对Twitter新上线的功能进行安全测试。

2.将功能开放给特定的第三方（或在公开API之前）不意味着你就不用对该功能的安全性进行测试了，有时我们只需要找到一个访问API的方法，我们也许就能轻松地找出其中存在的安全问题。当然了，如果厂商给特定服务设立了漏洞奖励计划的话，你也许就不必绕弯路了。

3.最后一点，当你没钱的时候，不要立刻放弃，你应该想办法绕过或避免那些需要你花钱的东西。不过你也可以换个角度考虑，人们一般都不喜欢去投资那些所谓的“不确定性”，这也就意味着如果某个服务需要收费，说明会有一部分人不愿意花钱去测试，那你就很有可能从中发现一些别人无法发现的漏洞了。如果这个服务又有漏洞奖励计划的话，那你估计就要发财了。

参考资料

关于该漏洞的详细技术分析以及PoC，请参考发布在HackerOne上的原始报告。

* 参考来源：innerht， FB小编Alpha_h4ck编译，转载请注明来自1024rd.COM
2017 年 9 月 7 日
挖洞经验 | 价值1万美金的谷歌内部主机信息泄露漏洞

文章讲述了乌拉圭17岁高中生Ezequiel Pereira发现谷歌内部主机信息泄露漏洞的过程，该漏洞获得了谷歌方面10000美金赏金，Ezequiel Pereira本人也因此进入Google漏洞名人堂。

漏洞发现过程

7月11那天，我闲来无聊，所以就打算找找谷歌的漏洞。经过对谷歌不同应用服务接口的大量测试后，我发现，在向Google App Engine（GAE）服务*.appspot.com发起请求的过程中，可以在其request中改变主机头信息，间接指向访问谷歌内部服务系统*.googleplex.com的。为此，用Burp来进行一些直观地操作和观察：

Google App Engine：GAE，是一个开发托管网络应用程序的平台，可让你在 Google 基础架构上运行自己的网络应用程序。其应用程序易于构建和维护，并可根据你的访问量和数据存储需要的增长轻松扩展。使用 Google App Engine，将不再需要维护服务器：只需上传你自己的应用程序，便可立即生成和提供服务。

谷歌内部服务系统：https://googleplex.com或https://login.corp.google.com/，为谷歌内部员工作业服务系统。

在不断变换的主机头请求信息中，大部份都为无效，要么返回404响应，要么设置了谷歌内部人员账户认证。但只有一个内部系统网站yaqs.googleplex.com，不需任何安全验证。

在对该内网请求的过程中，访问其主页会被重定向到/eng页面下，该页面非常有意思，包含了很多谷歌应用服务和网络架构的链接节点，但当我进一步访问时，却在页脚处显示了：”Google Confidential”（谷歌内部机密信息）字样。

漏洞上报

到此，我停止了继续浏览，立即向谷歌安全团队上报了该问题。所以，也没来得及对该问题进行一个直观的验证说明，按理来说，可以以下方式的PoC来作出描述：

curl -k “https://yaqs.googleplex.com” –resolve “yaqs.googleplex.com:443:172.217.28.180″

在给谷歌的漏洞问题上报中，我简单的说明了问题，以下为上报漏洞邮件大概：

漏洞概要：

从Google App Engine请求中获得对谷歌机密网站的访问权

重现步骤：

使用BurpSuite

1、在Repeater模块下

2. 将目标主机设置为 “www.appspot.com“, 目标端口设置为”443″ ，勾选”Use HTTPS” 选项

3、写入以下HTTP请求（结尾包括两个空行）

GET /eng HTTP/1.1

Host: yaqs.googleplex.com

4、点击发送”Go”

攻击场景：

任何人可以访问到谷歌内部名为YAQS，并标有“谷歌机密”的应用系统；

我不清楚网站的具体内容和用途，我仅只对其主机进行了访问浏览，你们可以从服务访问日志进行核实（我的IP是x.x.x.x，来自乌拉圭）

漏洞证明：

Burp的请求信息截图

几个小时之后，谷歌安全团队就进行了有效验证，并给我回应：

中大奖

我暗自心想，这就是一件不值一提的小事而已，其网站中包含的东西可能也就是一些技术文档资料的东西。但几个星期后，也就在我学校放假期间，我收到了谷歌的邮件回复。邮件中说，经过谷歌漏洞赏金项目组评审，我上报的那个漏洞问题可以得到10000美金的赏金，还能进入漏洞名人堂！哇…..，此刻的心情就像中奖一样！

该漏洞在于可以更改请求包中的主机头请求信息，对谷歌内部网站发起请求，攻击者可以藉此获取谷歌的一些敏感数据，目前已被谷歌修复。

漏洞上报进程

7月11日, 10:13 AM 漏洞上报

7月11日, 02:44 PM     漏洞分类

7月11日, 04:46 PM    谷歌回复有效

8月4日, 12:55 PM 赏金回复

8月4日 , 05:07 PM 出于好奇，向谷歌方面询问了漏洞危害，并征求漏洞公开意见

8月5日, 05:37 AM 谷歌方面给予回复

*参考来源：site.google，1024rd小编clouds编译，转载请注明来自1024rd.COM

2017 年 9 月 7 日
如何确认Google用户的具体电子邮件地址（已提交Google漏洞奖励计划）
近期我向Google报告了一个安全问题，这个漏洞将允许攻击者确认某Web页面的访问者是否登录了任意一个Google服务的账号（包括GSuite账号在内）。

根据我的测试结果，攻击者可以在每25秒钟的时间里确认大约1000个电子邮箱账号。但是Google方面给出的回复是：这是一个专门设计的功能，它并非是一个安全漏洞。

你可以在这个【演示页面】自行测试该功（lou）能（dong）。

首先给大家先上一个PoC演示动图（测试账号是我自己的邮箱）：

方法论

我之前曾经写过一篇关于“识别用户是否登录了某个社交网络”的文章，而本文所描述的攻击方式正是之前技术的变种版本。不过恕我直言，本文将要介绍的攻击方法影响会更加的严重。

Google的登录页面通常会在URL链接中传递一个continue参数，这个参数将负责把用户重定向到他们完成登录后原本需要访问的目的地址。但是如果你已经完成的登录的话，你将会立刻被重定向到continue参数所定义的URL地址。

这样一来，攻击者就可以利用这种运行机制并通过一个专门制作的URL地址来将已登录的用户重定向到一个图片文件，并呈现一个伪造的登录页面来尝试欺骗用户完成登录操作。如果你现在在img标签的src属性中使用这种URl地址的话，你就可以使用JavaScript的onload和onerror函数来确定图片是否已经正确加载了。

如果图片成功加载，说明用户完成了登录操作；如果图片加载出现错误，则说明用户没有登录。这个问题其实Google早就已经知道了，不过这种功能也有一定的局限性，并且无法造成严重的影响，所以Google并没有理会。

但是这个问题并不是Google想象的那么简单，因为攻击者现在还可以提供一个额外的参数来指定一个电子邮件地址。这也就意味着，如果攻击者提供的电子邮件地址能够与目标用户的邮件地址相匹配，则会触发一次重定向。

这样一来，攻击者就可以通过JavaScript的onload属性来动态创建并加载一个图片标签（这个过程不需要将图片对象添加到Web页面，而且你甚至都不需要将其附加到页面的DOM树中），然后等待匹配完成即可。在我的测试过程中，我可以每23-24秒的时间里检测大约1000个电子邮箱地址。如果目标用户登录了你的网站并停留了几分钟的话，你就可以检测好几千个邮箱地址了。

但是现在我们需要配合一些其他的方法来收集目标用户的部分基本信息，例如通过IP地址来了解到他们的地理位置，使用有针对性的社交广告来收集关于他们企业网络或其他的一些基本信息等等。如果顺利的话，你现在应该已经能够动态加载一份目标地址列表了。接下来，你就可以通过本文所介绍的技术来匹配并记录下目标用户的邮箱地址、IP地址、地理位置、设备信息以及其他各种各样的信息了。

现在，你就可以利用刚才所收集到的信息来发动动态网络钓鱼攻击了。

漏洞披露时间轴
```
2017年7月14日：我将这个问题报告给了Google的安全团队； 2017年7月17日：该问题已被分类，并等待处理结果； 2017年7月18日：Google安全团队与我联系，并询问我关于处理该漏洞的建议； 2017年7月18日：我给他们的建议是，在电子邮件中采用某种随机数或加盐哈希，并且只有在哈希和邮件相匹配的情况下才允许进行重定向； 2017年7月19日：Google确认将该问题归类为安全漏洞； 2017年7月21日：我发布了一篇文章对该漏洞进行了详细描述； 2017年8月9日：Google团队在经过讨论之后，告诉我这是一个专门设计的功能，并表示不会将其视为一个安全问题，因此他们不会采取任何下一步操作；
```
总结

这种攻击技术的确有一定的局限性，因为你必须事先获得一份目标用户列表。虽然Google安全团队并不认为这是一个安全漏洞，但是我仍然非常感谢他们，感谢他们能够对我提交的信息及时回复，他们非常的友好。

* 参考来源：tomanthony， FB小编Alpha_h4ck编译，转载请注明来自1024rd.COM
2017 年 9 月 7 日
量子计算机研究取得新突破：用现有技术生产量子芯片

来源：新浪科技

北京时间9月6日晚间消息，澳大利亚研究人员日前宣布，他们发明一种构建量子计算机的新方法，能以更简单、更廉价的方式批量生产量子计算机。

量子计算机是一种遵循量子力学规律进行高速数学和逻辑运算、存储及处理量子信息的物理装置，它能利用亚原子粒子的神奇力量来解决一些对于当前算机而言过于复杂或过于耗时的问题。

当前，谷歌和IBM等科技公司都在利用各种方法来开发量子计算机。而澳大利亚新南威尔士大学一组研究人员日前表示，他们利用新型量子位（quantum bit，量子计算机的最小信息单位）发明了一种新型芯片。

这种新型芯片设计能让硅量子处理器克服当前所存在的两个局限：1）必须精准放置原子；2）原子必须放开放置，但又要相互连接。

新南威尔士大学发明的这种新量子位被称为“触发器量子位”（flip-flop qubit），该项目负责人安德里亚·梅洛（Andrea Mello）称，这种新设计允许人们使用与生产当前计算机芯片同样的设备技术来生产量子处理器。

梅洛说：“这意味着构建量子计算机变得更加可行，因为它使用的制造技术与当前计算机行业所使用的技术相同。”

这意味我们将可以批量生产量子计算机芯片，而在此之前，这一直是令研发人员头痛的问题。

当前，IBM的量子计算机拥有16量子位，意味着它只能执行一些基础的计算。而谷歌的量子计算机仅拥有9量子位。

相比之下，当前的台式机计算速度达到了每秒10亿次浮点运算，全球最快的超级计算机——中国的“神威太湖之光”——的计算速度达到了每秒9.3亿亿次浮点运算。

但理论上讲，一台小型的30量子位通用量子计算机的运行速度，相当于一台每秒10万亿次浮点运算的普通计算机的运算速度。

德克萨斯A&M大学教授拉斯洛·凯什（Laszlo Kish）称，目前判断这项发明是否是“突破性的”还为时尚早，但在解决量子计算的核心问题上，他们可能向正确的方向迈进了一步。

如今，在获得澳洲电信、澳大利亚联邦银行、澳大利亚和新南威尔士政府的投资后，新南威尔士大学成立了“硅量子计算有限公司，计划在2022年打造出10量子位原型硅量子集成电路，为打造全球第一台硅量子计算机做准备。

点击阅读原文查看更多

2017 年 9 月 7 日
软件定义无线电（SDR）技术发展历史简介

来源：头条号/芯思维作者：王志杰

软件定义无线电（SDR）不是新技术，已为很多的无线设备（除了制造低成本基于ASIC的低功耗设备，如智能手机和平板电脑）广泛所采用。自SDR首次提出以来已有30多年了，下面简单介绍下在SDR三十年演进历史中的主要事件。

▌1984年 E-System创造出“软件无线电”术语

E-Systems，就是现在的雷神，在一份公司的新闻稿里创造了“软件无线电”一词。它提到了一个数字基带接收机原型，配备了处理器阵列，处理宽带信号的干扰消除和解调的自适应滤波。

▌1991 SPEAKeasy

第一个军事计划是DARPA的SPEAKeasy，专门要求用软件来实现物理层组件的无线电功能。最初美国空军的首要目标是单台无线电可以支持十种不同的军用无线电协议并工作在2MHz和2GHz之间任意频率。第二个目标是并入新协议和调制的能力，从而可以适应未来的无线电硬件。从DARPA的描述来看，“SPEAKeasy是企图创建无线电世界的PC”。

▌1992 Joseph Mitola在IEEE发表了软件无线电论文

Joe Mitola在1992年 IEEE 美国电信系统会议（National Telesystems Conference）上发表了关于软件无线电的论文 – “Software Radio: Survey, Critical Analysis and Future Directions”。许多人将其称为软件无线电教父，Miltola也被认为创造了”软件无线电“一词的人，尽管E-Systems先用了。 E-Systems原型机仅仅是一个接收机，因此不是一个完整无线电。后来，1998年Mitola又提出了“认知无线电”概念，无线电可以意识到其频谱环境，并根据需要智能适应。

▌1996 SDR论坛创立

1996年，致力于SDR的第一个行业协会成立 – “模块化多功能信息传输系统（MMITS，The Modular Multifunction Information Transfer System）论坛”。1998年变成了SDR论坛，在2010年又成为了无线创新论坛。论坛由来自政府、行业和学术界的人员和组织组成，推进发展SDR相关技术为目标。它组建了多个工作组和委员会，以激励和引导创新和标准。

▌1997 JTRS创立

JTRS是Joint Tactical Radio System (联合作战无线系统)的缩写，由美国国防部创建，通过抽象层和接口的标准化和定义提高互操作性和博兴可以移植性，称为软件通信架构（SCA， Software Communication Architecture）。数十亿的计划雄心勃勃，在经历了困难、延期和成本超支之后，于2011年被美国国防部副国务卿正式取消了该计划，认为产品和技术不可能满足既定的要求。然而，它却极大地促进了SDR数十年的发展进步。像Rohde & Schwarz、Thales和Harris等设备制造商已经在部署符合SCA的无线电。此外，欧洲防务局设立了欧洲安全软件定义无线电（European Secure Software Defined Radio，ESSOR）计划，继续JTRS SCA的工作。

▌1998 嵌入式SDR自动代码生成

Nutaq（后来的Lyrtech）与MathWorks合作创建了第一个开发环境，可以从TI DSP和Xilinx FPGA的仿真模型直接生成可执行代码。这一创新解决了开发人员和研究人员一个大难题：为嵌入式处理器写代码。DSP和FPGA配置在SignalMster的板上，与A/D和D/A模块连接，是实验室和大学搭建原型首批商业化的SDR开发平台之一。

▌2001 GNU Radio

由MIT的一个PSpectra框架演变而来，GNU Radio由Eric Blossom创立，Sun Microsystems的员工John Gilmore资助。 GNU Radio是PC环境开发SDR应用的开源框架。截至2012年已拥有5000多个用户，是目前最流行的SDR开发工具。齐全的波形支持，如P25、802.11、ZigBee、蓝牙、RFID、DECT、GSM，甚至是LTE（仍在进行中）都可以从存储库下载并运行在任何的x86系统上。

▌2004
FCC首次批准商业化SDR

Vanu公司的Anywave基站成功地通过了FCC（ Federal Communications Commission，美国联邦通讯委员会）认证。Anywave是一个能够同时运行GSM和CDMA两个运营商的双模基站，所有协议层在x86 CPU上运行。Vanu公司是由Vanu Bose创立，MIT Pspectra框架的主要贡献者。

▌2004 PHY处理器

Picochip（现在的 Mindspeed Technologies）推出了PC102，专为PHY处理（通常称为基带处理器）而设计的处理器。PC102针对3G基础设施市场，有308个处理单元，14个专用协处理器（加速器）和能处理MAC层以及其他协议的单元。PC102板子大大减少了无线设备的尺寸、成本和功耗。Picochip是新一代专业处理器的发起者。它为新的玩家铺平了道路，如Octasic的24核OCT2224W和Coherent Logix的HyperX系列，促使传统供应商提出SDR优化的架构，产生了TI的Keysto系列和Freescale的QorIQ。

▌2006年 TI和Xilinx一起推动嵌入式SDR开发

Texas Instruments和Xilinx与Nutaq（后来的Lyrtech）一起合作，创建了第一个完全集成独立的SDR开发平台。它配备了一个ARM、一个DSP、一个FPGA和一个可调的前端，频率从200 MHz到1 GHz。该平台比鞋盒小，而且可以由电池供电，这为SDR走出实验室的应用和实验开辟了新的可能性。

▌2008 Sandbridge Technologies推出基带处理器

Sandbridge Technologies推出了SB3500基带处理器，能够在任何通用的多模、多功能移动平台所需的无线协议上运行。其架构创新为当今使用或为今后开发的任何无线协议提供可升级的性能，包括LTE、HSPA、3G WiMAX、Wi-Fi、DVB-H、GPS以及所有多媒体格式。2011年 Sandbridge Technologies公司被无锡德思普公司所收购。

▌2009 第一款商用单芯片射频前端

Lime Microsystems公司推出了射频集成电路（RFIC）LMS6002。随后又推出了LMS6002D，已集成了数据转换器。 RFIC在400 MHz和4 GHz之间任意可调，支持高达28 MHz带宽，并提供一个可选的16位基带滤波器组。此后，其他芯片厂商也开始提供RFIC解决方案。

▌2015 微软研究院软件无线电项目Sora开源

2015年微软研究院软件无线电项目Sora(Microsoft Research Software Radio)正式通过GitHub开源。Sora的软硬件平台的创新使得它可以在PC上完成高性能的无线信号处理。

华为、中兴早在一些网络基础设施上采用了SDR技术。2015年联芯发布的28nm SoC智能手机芯片平台LC1860直接让SDR技术应用到了小米公司的红米2A。SDR在手机上的成功应用，也意味着一个无线新时代的到来。SDR正在逐步应用到更多的产品和领域，芯片技术的发展是SDR技术发展的推动力。SDR可以支持无限量的通讯协议和多媒体应用，这得益于SDR芯片的计算能力。物联网、5G等网络的发展会给SDR带来新的发展空间。而近几年发展起来的“异构系统架构”（HSA，Heterogeneous System Architecture）技术的将会为SDR技术发展注入带来新的活力。

最后，看一看NI公司对SDR的发展的描绘：

点击阅读原文查看更多

2017 年 9 月 6 日