前段时间有位好友，搬家，结果新的二房东竟然私装电表，计价1.5元/kwh，于是本着求知欲就帮忙看了下。
通过查看电表铭牌，发现为某品牌单相蓝牙电能表，具体使用流程为，电表上附有一个二维码，扫码后打开微信小程序xx水电智能管家，通过小程序储值后，会通过蓝牙同步信息给电表。
通过此工作方式，初步判断此表本身不具备联网校验能力。
背景调查
但是处于稳妥考虑，我依旧到淘宝上找到了卖同款表的商家，再次确认，是否有远程抄表等功能，得到了与我猜测一致的结果。同时与商家沟通了解到，该表也可以在出厂时，调节度量精度，即1 KWh的用量，可以量出来最多1.5KWh，相当于增加了50%，但是幅度仅能由厂家调节，发货后，不能再调节。
分析
反编译微信小程序
这一步已经很成熟了，这里就不过多赘述，我自己图方便，是通过PC版小程序解密得到。
分析代码
可以看到目标小程序并没有什么安全措施，很快在一个名为rechargeV2.js的文件中发现相关逻辑
createPayOrder: function(a, o, t) {
var n = this;
e.request({
url: c.default.apiUrl + "/zk-payment/create",
method: "POST",
header: {
"Content-Type": "application/x-www-form-urlencoded"
},
data: {
accessToken: n.accessToken,
plathForm: "zk",
money: t,
payMoney: o,
deviceId: n.deviceData.id,
openId: a
},
success: function(a) {
console.log("支付订单参数", a.data);
var o = a.data;
if ("success" == o.code) {
var i = o.data.recordId, r = o.data.buyNum, s = parseInt(o.data.buyTimes) + 1;
e.requestPayment({
provider: "wxpay",
timeStamp: o.data.timeStamp,
nonceStr: o.data.nonceStr,
package: o.data.package,
signType: o.data.signType,
paySign: o.data.paySign,
success: function(a) {
console.log("rechargeId", i);
var o = 30, l = setInterval(function() {
console.log("request query " + o), o--, e.request({
url: c.default.apiUrl + "/zk-payment/query-recharge",
method: "POST",
header: {
"Content-Type": "application/x-www-form-urlencoded"
},
data: {
accessToken: n.accessToken,
plathForm: "zk",
deviceId: n.deviceData.id,
rechargeId: i
},
success: function(e) {
var a = e.data;
"success" == a.code && 1 == a.data.status && (clearInterval(l), o = 0, n.wechatPayAction(t, r, s));
},
fail: function(e) {
console.log("失败", e);
}
}), o
在调用充值，并通过服务端确认充值完毕后，最终调用了getOrder方法后，随即通过蓝牙向电能表写入数据，一些参数说明，已经写在代码中
getOrders: function(a, o) {
var t = this, n = "no";
t.isLeftMoney && (n = "yes"), e.request({
url: c.default.apiUrl + "/zk-order/create",
method: "POST",
header: {
"Content-Type": "application/x-www-form-urlencoded"
},
data: {
accessToken: e.getStorageSync("accessToken"),
plathForm: "zk",
deviceCode: t.deviceCode, //
上面的请求中有个buyCount参数，用于防止中间人对电能表进行重放攻击，也就是说，当表内记录的buyCount数大于等于请求数据内的buyCount时，电能表会直接忽略这次请求。
除了这一个小小的特殊点以外，其他并无特别，拿到服务端的数据后，也没有过多的操作，即通过蓝牙写入数据
writeBLECharacteristicValue: function(a) {
var o = arguments.length > 1 && void 0 !== arguments[1] ? arguments[1] : "", t = arguments.length > 2 && void 0 !== arguments[2] ? arguments[2] : 0, c = this, i = n.default.hex2buffer(a);
// 中间有一大段无效代码 在此省略
e.setBLEMTU({
deviceId: c.bleData.bleDeviceId,
mtu: 100,
success: function() {
e.writeBLECharacteristicValue({
deviceId: c.bleData.bleDeviceId,
serviceId: c.bleData.bleServiceId,
characteristicId: c.bleData.bleCharacteristicIdWrite,
value: i, //
对照微信关于蓝牙相关的开发文档，可以知道这是BLE蓝牙通讯，且并无特别之处。
因此可以看出，整个服务端几乎没有什么校验，接下来正常充值一个，看看具体向电能表写入了什么数据呢？
DLT645-2007 ?
通过PostMan发送相同的请求，得到服务端返回的数据格式为68XXXXXXXXXXXX68141869F8A38207A3EF88ECFE96D2622E87F4016E521BA10796F2EC16，其中XX部分为设备ID，已脱敏。
从整体格式上看，非常像DLT645协议（这是后话了，当初我并不知道有这个协议，花了一些分析，在查着资料时，发现有这个协议），于是立马找了一份文档，发现其结构基本符合DLT645，但是数据域似乎是自定义了，或者说被加密了
如果有懂的大佬，也请告诉我，这是厂家自行魔改的，还是说也是某种规范？
对于同一个充值请求，每次返回的写入数据并不一致。
68XXXXXXXXXXXX68141869F8A38207A3EF88ECFE96D2622E87F4016E521BA10796F2EC16
68XXXXXXXXXXXX68141869F8A38207A3EF88523ABCC12E588865B64E007EE2EF123EA216
68XXXXXXXXXXXX68141869F8A38207A3EF88B66E992139D84BE61B5D0D87EA4B9A49C716
比如，上面的三组数据，都是来自于同一个充值请求，且效用也都一样，任意一个数据发送到表后，其余的都不在有效。
考虑到电能表的计算能力比较一般，通常不会采用比较复杂的运算，初步推测是一些简单的偏移量加减或者异或运算，但是鄙人不才，获取了上千组数据后，仍未分析出数据域经过了什么改造。
总结
整个流程为：
1.用户扫码 -> 2.小程序支付 -> 3.获取写表数据 -> 4.BLE向电能表写入数据 -> 5.电能表处理后，返回数据 -> 6.电能表返回数据送回服务端
但是服务端也很神奇，因为生成数据的结构（即步骤3.），即不校验订单（是否存在有效的支付订单），也不校验金额（请求生成的金额是否与订单支付一致），因此可以任意填写充值金额，并获得写表的数据。最终实现白嫖。当然这一步有可能是服务端会有记录的。
由于最终卡在了电能表接受的数据上，不能自主生成（也确实猜不到数据域到底是如何自定义的），最后还是得依赖于服务端的接口，所以这一次的任务，完成的并不完美。但是并不影响白嫖，写个小工具，只需要完成3.4.两步即可正常使用。
后续在翻看小程序代码时，发现getOrders方法的orderType还有其他可选的几组值，可以实现开闸/合闸/清表等操作，请求这些操作也没有更多的鉴权。在向表发送相关数据后，也确实可以实现相关功能。
如果有相关行业的大佬，知道应该如何解析其每次都变化的数据域，希望您可以不吝赐教。
