A friend returned from San Diego Comic Con 2018 with an RFID bracelet used to track users in the Amazon Fire TV experience (on Twitter, #FireTVSDCC). This is a teardown of the bracelet after the event. At this time, I was unable to read from the bracelet.
The bracelet is fairly simple with a cloth band and plastic/paper tab threaded through. The closure is plastic and one-way. It bites into and mangles the cloth band if you attempt to remove, but you could probably shim it with tools and practice. Might be a fun thing for the Tamper Evident Village if it turned out events were trying to use this for access control like plastic self-destructing wristbands.
The back contains a serial number. I would like to see if this serial number would match the data read off the tag.
Separating the badge by prying them apart, I spot the prize: an adhesive RFID tag placed between the glossy plastic covers. It appears to have a model number of "CXJ-040" in the center of the tag. It uses a circular antenna. CXJ is the initials of Shenzen manufacturer Chuangxinjia. Their product pages show manysimilarwristbands in a few different frequencies.
The tag didn't respond to my Android phone, so it is not a Mifare or similar. Hopefully I can find a reader at the local Hackerspace or DEF CON 26.
It turns out that using the convenience function ENCRYPT$ENCRYPT_ONE_RECORD on OpenVMS for AES CBC does something squirrelly. It will not let you pass in an IV. Instead, ENCRYPT$INIT sets the IV to 16 bytes of \0. In order to ensure your identical plaintext first blocks aren't identical after encryption, your first 16 byte block needs to be your true IV. This will get XORd with the null byte encrypted IV and sufficiently scrambled so your second block can be uniquely encrypted. OR just do it right and avoid the convenience method. Use ENCRYPT$INIT properly.
"For AES, the optional P1 argument for the AES IV initialization vector is a reference to a 16-byte (2 quadword) value.
If you omit this argument, the initialization vector used is the residue of the previous use of the specified context block. ENCRYPT$INIT initializes the context block with an initialization vector of zero."
Terminal.app and iterm2 can be used on Mac interact with an OpenVMS system by setting the right profile settings and keys with escape sequences. Most keys work by default (PF1-PF4 when Fn is used to disable Mac system interactions), but it must be configured correctly to allow access to other keys commonly used in OpenVMS terminal applications (FIND, PREV, NEXT).
PF1-PF4
The F1 - F4 function keys will work as PF1-PF4 if Fn is pressed as well.
If your keyboard is a large Mac keyboard with a Fn key above the arrows, access PF1 - PF4 by turing off the Mac keyboard options (brightness, volume controls, etc) by holding the Fn key and pressing F1 - F4. This also works for some other function keys. Smaller keyboards will need to map F13+.
If you are on a PC keyboard, you can disable the Function Keys functions in System Preferences and return them to act as F1 - F4.
If you don't want your function keys to always act as F1 - F4, the program FunctionFlip can be used to change your function keys back and forth on the fly.
Accessing Keys with Shift and Alt
Some keys are mapped, but not accessible without using Shift and Alt in combination with the above Fn key/FunctionFlip.
Here are Terminal.app configs:
F11: Alt F6
F12: Alt F7
HELP: F15 on an extended keyboard or Shift F7
DO: F16 on an extended keyboard or Shift F8 or Alt F11
F17: Shift F9 or Alt F12 or F17 on an extended keyboard
F18: Shift F10 or F18 on an extended keyboard
F19: Alt F14 on an extended keyboard or F19 on an extended keyboard or map it (see below)
F20: Shift F12 or Alt F15
Some of the above work for iterm2. Here are alternate mappings:
F11 can be accessed with Control F11
F20 will need to be mapped to a key of your choice using escape sequence [34~
Mapping Other Keys
Other keys can be mapped within Terminal.app or iterm2 by making a profile.
For Terminal.app:
Open a terminal
Go to the Terminal menu, Preferences.
Add a new profile with the + button at the bottom left.
Name it 'OpenVMS'.
On the Text tab, adjust the colors so you can differentiate it from your other terminal windows.
On the Window tab, adjust the Window Size to 132 Columns if your terminal apps support this width.
You may need to enable the keypad mode to get access to LSE's navigation keys on the keypad (PF1+4 or 5 to seek to the bottom/top).
On the Keyboard tab, you can add mappings to individual keys that OpenVMS needs for navigation. This is useful in LSE or other text editors. Choose a Key to map and then enter a mapping. Mappings are entered by typing a control character `Ctrl + [` (will appear as \033) followed by some additional keystrokes. The following mappings have been found and are based on this Google Groups thread:
OpenVMS Key
Key
Action
FIND
Home
\033[1~
PREV
PgUp
\033[5~
NEXT
PgDown
\033[6~
SELECT
End
\033[4~
F19
^ F9
\033[33~
F20
^ F10
\033[34~
For iterm2, use Profiles:
Use similar escape sequences for the FIND and similar keys as above. On Profiles, Keys tab: add a hotkey and select "Send Escape Sequence" for the action. Omit the \033 from the table above. FIND end up as "Send [1~".
Enable Keypad mode for navigating in LSE. Profile, Keys, keypad mode checkbox. This only works for extended keyboards.
Above is Dan Kaminsky's keynote at the inaugural DEF CON China. It was nominally about Spectre and Meltdown, and I thought it was immediately applicable to testing at all levels. Here are some moments that jumped out at me:
On Context:
"There's a problem where we talk about hacking in terms of only software...What does hacking look like when it has nothing to do with software." 1:55
"But let's keep digging." Throughout, but especially 5:40
"Actual physics encourages 60 frames per second. I did not expect to find anything close to this when I started digging into the number 60...This might be correct, this might not be. And that is a part of hacking too." 6:10
"Stay intellectually honest as go through these deep dives. Understand really you are operating from ignorance. That's actually your strong point. You don't know why the thing is doing what it is doing...Have some humility as you explore, but also explore." 7:40
"We really really do not like having microprocessor flaws...and so we make sure where the right bits come in, the right bits come out. Time has not been part of the equation...Security [re: Specter/Meltdown] has been made to depend on an undefined element. Context matters." 15:00
"Are two computers doing the same thing?...There is not a right answer to that. There is no one context. A huge amount of what we do in hacking...is we play contexts of one another." 17:50
[Re: Spectre and Meltdown] "These attackers changed time which in this context is not defined to exist...Fast and slow...means nothing to the chip but it means everything to the users, to the administrators, to the security models..." 21:00
"Look for things people think don't matter. Look for the flawed assumptions...between how people think the system works and how it actually does." 35:00
"People think bug finding is purely a technical task. It is not because you are playing with people's assumptions...Understand the source and you'll find the destination." 37:05
"Our hardest problems in Security require alignment between how we build systems, and how we verify them. And our best solutions in technology require understanding the past, how we got here." 59:50
On Faulty Assumptions:
"[Example of clocks running slow because power was not 60Hz] You could get cheap, and just use whatever is coming out of the wall, and assume it will never change. Just because you can doesn't mean you should...We'll just get it from the upstream." 4:15
"[Re: Spectre and Meltdown] We turned a stability boundary into a security boundary and hoped it would work. Spoiler alert: it did not work." 18:40
"We hope the design of our interesting architectures mean when we switch from one context to another, nothing is left over...[but] if you want two security domains, get two computers. You can do that. Computers are small now. [Extensive geeking out about tiny computers]" 23:10
"[RIM] made a really compelling argument that the iPhone was totally impossible, and their argument was incredibly compelling until the moment that Steve Jobs dropped an iPhone on the table..." 25:50
"If you don't care if your work affects the [other people working on the system], you're going to crash." 37:30
"What happens when you define your constraints incorrectly?... Vulnerabilities. ...At best, you get the wrong answer. Most commonly, you get undefined behavior which in the presence of hacking becomes redefinable behavior." 41:35
"It's important to realize that we are loosening the assumption that the developer knows what the system is supposed to do...Everyone who touches the computer is a little bit ignorant." 45:20
On Heuristics
"When you say the same thing, but you say it in a different time, sometimes you're not saying the same thing." 9:10
"Hackers are actually pretty well-behaved. When hackers crash code...it does really controlled things...changing smaller things from the computer's perspective that are bigger things from a human's perspective." 20:25
"Bugs aren't random because their sources aren't random." 35:25
"Hackers aren't modeling code...hackers are modeling the developers and thinking, 'What did [they] screw up?' [I would ask a team to] tell me how you think your system works...I would listen to what they didn't talk about. That was always where my first bugs came from." 35:45
On Bug Advocacy
"In twenty years...I have never seen stupid moralization fix anything...We're engineers. Sometimes things are going to fail." 10:30
"We have patched everything in case there's a security boundary. That doesn't actually mean there's a security boundary." 28:10
"Build your boundaries to what the actual security model is...Security that doesn't care about the rest of IT, is security that grows increasingly irrelevant." 33:20
"We're not, as hackers, able to break things. We're able to redefine them so they can't be broken in the first place." 59:25
On Automation
"The theorem provers didn't fail when they showed no leakage of information between contexts because the right bits went to the right places They just weren't being asked to prove these particular elements." 18:25
"All of our tools are incomplete. All of our tools are blind" 46:20
"Having kind of a fakey root environment seems weird, but it's kind of what we're doing with VMs, it's what we're doing with containers." 53:20
On Testing in the SDLC
"We do have cultural elements that block the integration of forward and reverse [engineering], and the primary thing we seem to do wrong is that we have aggressively separated development and testing, and it's biting us." 38:20
"[Re Penetration Testing]: Testing is the important part of that phrase. We are a specific branch of testers that gets on cooler stages...Testing shouldn't be split off, but it kinda has been." 38:50
Ctd. "Testing shouldn't be split off, but it kinda has to have been because people, when they write code, tend to see that code for what it's supposed to be. And as a tester, you're trying to see it for what it really is. These are two different things." 39:05
"[D]evelopers, who already have a problem psychologically of only seeing what their code is supposed do, are also isolated from all the software that would tell them [otherwise]. Anything that's too testy goes to the test people." 39:30
"[Re: PyAnnotate by @Dropbox] 'This is the thing you don't do. Only the developer is allowed to touch the code.' That is an unnecessary constraint." 43:25
"If I'm using an open source platform, why can't I see the source every time something crashes? ...show me the source code that's crashing...It's lovely." 47:20
"We should not be separating Development and Testing... Computers are capable of magic, and we're just trying to make them our magic..." 59:35
Misc
"Branch Prediction: because we didn't have the words Machine Learning yet. Prediction and learning, of course they're linked. Kind of obvious in retrospect." 27:55
"Usually when you give people who are just learning computing root access, the first thing they do is totally destroy their computer." 53:40 #DontHaveKids
"You can have a talent bar for users (N.B.: sliding scale of computer capability) or you can make it really easy to fix stuff." 55:10 #HelpDesk
"[Re: Ransomware] Why is it possible to have all our data deleted all at once? Who is this a feature for?!... We have too many people able to break stuff." 58:25
During my second Postman meetup as part of the Las Vegas Test Automation group, we were able to cover some of the more advanced features of Postman. It's a valuable tool for testing RESTful services (stronger opinions on that also exist), and they are piling on features so fast that it is hard to keep track. If you're a business trying to add automation, Postman is easily the lowest barrier to entry to doing so. And with a few tweaks (or another year of updates) it could probably solve most of your API testing.
The meetup covered the Documentation, Mock Server and Monitor functionality. These are pieces that can fit in your dev organization to smoothe adoption, unroadblock, and add automation with very little overhead. Particularly, the Mock servers they offer can break the dependency on third party integrations quite handily. This keeps Agile sprints moving in the face of outside roadblocks. The Monitors seem like a half-measure. They gave a GUI for setting up external monitors of your APIs, but you still need Jenkins and their Newman node package to do it within your dev env. The big caveat with each of these is that they are most powerful when bought in conjunction with the Postman Enterprise license. Still, at $20 a head, it's far and away the least expensive offering on the market.
Since the meetup, I've found a few workarounds for the features I wish it had that aren't immediately accessible from the GUI. As we know in testing in general, there is no one-size fits all solution. And the new features are nice, but they don't offer some of the basics I rely on to make my job easier. Here is my ever-expanding list of add-ons and hidden things you might not know about. Feel free to comment or message me with more:
Postman has data generation in requests through Dynamic Variables, but they're severely limited in functionality. Luckily, someone dockerized npm faker into a restful service. This is super easy to slip stream into your Postman Collections to create rich and real-enough test data. Just stand it up, query, save the results to global variables, and reuse them in your tests.
The integrated JavaScript libraries in the Postman Sandbox are worth a fresh look. The bulk of my work uses lodash, crypto libraries, and tools for validating and parsing JSON. This turns your simple requests to data validation and schema tracking wonders.
Have a Swagger definition you don't trust? Throw it in the tv4 schema validator.
Have a deep tree of objects you need to be able to navigate RESTfully? Slice and dice with lodash, pick objects at random, and throw it up into a monitor. Running it every ten minutes should get you down onto the nooks and crannies.
This article on bringing the big list of naughty strings (https://ambertests.com/2018/05/29/testing-with-naughty-strings-in-postman/amp/) is another fantastic way to fold in interesting data to otherwise static tests. The key is to ensure you investigate failures. To get the most value, you need good logs, and you need to pay attention to your results in your Monitors.
If you have even moderate coding skills among your testers, they can work magic on a Postman budget. If you were used to adding your own libraries in the Chrome App, beware: the move to a packaged app means you no longer have the flexibility to add that needed library on your own (faker, please?).
The 27th Surveyors are part of the ground units on the death world Pholos IV. They remove invasive vegetation from settlements, patrol for xenos incursion, and quell uprisings among the rowdy recolonists.
The deep green robes with shocking yellow lining mirror the vegetation that sprouts, grows tall, and flowers often in the same day. The temperate latitudes pulse with these colors when viewed from space.
The surveying contingent can rely on support from giant machines. Knights with claws and saws for felling overnight forests, Onagers specially modified to traverse the decaying swamps thick with fungal rot, resurface roads thick with cracks only weeks after being layed down, and pulp the lignin and experimental protein bioheresy into specialized oils and unguents. The ruin wrought by the mad Biologis would be turned to the might of the Mechanicum at last.
The AC on my land yacht (2009 Mercury Grand Marquis) has been in the fritz for a while. Last winter, it gradually stopped switching from max AC/recirculate (a necessary in Vegas), then got stuck on norm AC until it rested on Defrost/Floor. I was able to fix it with some basic troubleshooting, YouTube sleuthing, and two bucks in o-rings.
The same video showed me how to diagnose the vacuum problems. The black hose providing vacuum from the engine seemed fine: I was getting 20 inches of vacuum with the car turned on when I hooked up a bleed pump with a gauge (mine came from Harbor Freight, shown in the video). To test the actuators, all I had to do was hook a 'jumper' pipe from black to the other pipes. Each one seemed to hold air, and the actuators sprang to life once again. For the first time in a year, I had cold air blowing from the vents. The problem couldn't be in the lines. I pulled the controller head for a closer look.
The head itself is a bunch of electronics, a control panel, and one removable plate with four solenoids. The vacuum hoses come into this through a manifold, and the head controls trigger the solenoids to route vacuum from the black hose to the others. This triggers different actuators under the dash. Something was amiss in the manifold.
I returned to YouTube looking for rebuild instructions. I found this extremely helpful video from a Chicago mechanic. The solenoids contain an o-ring that dries out, wears out, and loses the ability to hold vacuum. I obtained close to the recommended o-rings from Lowes (#36, 5/16 OD, 3/16 ID, 1/16 thickness) as I was not willing to wait for Amazon. A little Oatey silicone lubricant made the tight squeeze work a little better. I found I had to seat the solenoid heads at least once before total reassembly. It was too difficult to do so at the end and fight with the other small parts at the same time. 45 minutes later, I had full control of my AC restored.
I can't believe it was this simple to fix the controller. I think I was intimidated by the AC (having spent $1500 last year to have the dealer redo the whole system from seals to refrigerant). I didn't want to break anything. A few targeted troubleshooting steps helped assuage any fears of irreparable harm, and now I have a comfortable cabin once again.
