EVE-Central has received a minor site update today. Two new features were introduced:
Feel free to submit futher patches and features. I have a few patches to merge into Contribtastic and the website once they are tested.
I am working on the cache format change that was released in the latest EVE release. This may take a few days to sort out.
My Windows build machine is up and running again. Alpha 5 of Conttibtastic is prepackaged for testing.
As many of you noticed, Contribtastic Alpha4 is bugged. The code is fixed, but I haven’t had a functioning Windows build machine to turn the handle on in order to produce the installer package. Stay tuned.
A new version of Contribtastic, the 100% open source cache reading uploader, is now available. If you’ve been hit with the data.pickle corruption bug from previous versions, this is an essential upgrade.
Next release may actually add the CSV export option along with re-implementing login functionality. Contributions welcome!
I thought I’d do a small interlude into the embedded hardware and firmware space (which is generally my main area of work) from the normal EVE-Central heavy side of this blog. I have been musing about the code security protections of the MSP430 micro-controller, specifically the Boot Strap Loader (BSL), which remains enabled at all times, even if the JTAG interface is disabled (via a fuse on most MSP430s).
The BSL disallows memory reads and writes until a “password” has been transmitted over the serial interface. The password is actually a copy of the interrupt vectors (32bytes) used by the micro-controller, which limits the entropy available by a significant margin: addresses are all even aligned, reset vector is generally start of flash, many interrupt vectors will be identical, general case has all interrupt vectors located in flash. The only defense against this low-entropy brute force attack is the rate limit of the BSL: some versions of the BSL prevent you from changing from 9600 baud until after the password has been verified. However, on devices with small amounts of flash (say, 8Kib), there are only about 61,000 passwords generally in use, which reduces the search time tremendously.
Some BSL versions are also susceptible to side channel attacks are discussed in this paper:
Practical Attacks against the MSP430 BSL
Texas Instruments has improved code security on the new F5xxx series devices in a drastic way: an invalid password will cause a complete device erase. Note that the flash memory also differs from the previous generation devices by being rated to erase and program as low as 1.8V (where the core voltage normally sits – the 5 series has an integrated LDO).
I can see two possible attack vectors – undervoltage to the entire processor (I have a ’5438A running as low as 1.5V, however the BSL is not yet tested down here), or “glitching” the processor (in this case, complete power down) if the start bit of the acknowledgement packet is not transmitted within an allowable window. The second scenario can be defended against in the BSL firmware (delay the acknowledge by a large value).
I have not tried either of these attacks on the 5xxx series yet (specifically, the 5438 and 5438A). Generally, there are easier ways to attack processors to capture embedded code, or simply replicate external functionality based on observed behavior (code security is not on most programmers’ minds). If small-memory variants of the 5xxx series become available (to allow the brute-force searching of the keyspace), the flash memory erase issue would have to be overcome.
In the mean time, you can use some chip disassembly techniques from Flylogic.
On another note, I will be announcing a security related, open source hardware project shortly. Its been keeping me distracted from EVE-Central (trade route tool version 2, specifically), Contribtastic, and working on the EVE-Metrics/EVE-Central unified uploader.
I have had several questions regarding the “rle_unpack” function in libevecache. In order to not repeat myself in e-mails, I decided to make a quick post describing the logic:
The market rows are compressed with an odd variant of run-length-encoding. In this case, the extra “0″ bytes are suppressed and encoded into one byte.
The row starts with a opcode byte, which is split as follows (high bit to low bit). You can find this broken out in the struct packer_opcap.
x x x t y y y b
7 6 5 4 3 2 1 0
There “t” is a flag to say “unpack 0s” if the bit is set, and “copy from source” if the bit is not set. So if the bit is set, “XXX” bytes of “0″ are copied to the output buffer, and if its not set, “XXX” bytes are copied from the input to the output.
This repeats with B and YYY. After one opcode byte has been processed, the next opcode byte is read, or processing is terminated if the input buffer has been exhausted.
This took a fair bit of time to figure out, with lots of sample data and market logs as the study set.
How much space does it save per order row? About 10-30%, from my samples.
You heard CCP, Dominion lands on December 1st. Hopefully this major patch will be a little less buggy than some of CCP’s previous mass roll-outs. As for EVE-Central.com, I will be working hard to make sure all of the relevant new items (namely the sovereignty devices) are in the database near the launch. I will also be launching the updated user registration system next week (since the current one is literally broken, an unintended side effect). This update hasn’t yet hit the git repository, but stay tuned.
After things stabilize with Dominion, work will progress on the EVE-Central Batching Tradefinder 2.0, followed by some UI cleanups and statistics features.
Remember to set a long skill training!
An update for those of you using the EVE-Central mail push service:
Please note that each e-mail can now contain multiple types.
In addition, the daily dumps have had their Issued timestamps truncated out for a long time now. This issue has been resolved for all future dumps.
We’ve done some quick tuning to the SMTP push service to keep up with the much larger volume of traffic generated by the new uploader. You may notice that the e-mails now contain many types, concatenated together. It turns out that mailman is simply not ideal when distributing 100 e-mails a second 
For now, the worst case latency from upload to e-mail is 1 minute, with a fixed upper size per e-mail.
On another note: EVE-Metrics now uses AMQP to distribute uploads. We are reading the uploads from them and incorporating it into the EVE-Central stream and site.
TwitterPowered by WordPress