Little 418

Posted by Jen Tong on October 12, 2018

I’m a big fan of cleaning up after myself on the Internet. I even wrote some blog posts about it in the past.

One of the hard parts about cleaning up is deleting old content, like Tweets. It often requires time consuming manual deletion, or tinkering around with an API that changes each time you use it. There are websites that provide this service for Twitter, but they all require very aggressive OAuth permission grants, or (worse yet) your Twitter login credentials. I didn’t feel comfortable with either of those options.

So, inspired Norberth’s 2015 answer to a Quora question, I hacked up some JavaScript for deleting old Tweets from your console that works as of October 2018.

Here’s how to use it:

1. Read all of the code on this blog post. Understand it before you paste it into your console. Pasting random stuff into your console is very dangerous!
2. Fix the script, since it likely broke
3. Go to your twitter profile page.
4. Scroll down until there aren’t any more tweets to load.

5. Paste this JS into your web browser’s JavaScript console.

    // get all the buttons
    var buttons = $('.js-actionDelete button'); 
       
    // don't delete most recent 50
    buttonsOfTweetsToDelete = buttons.slice(50);
       
    function deleteTweet(tweets) {
    // exit if there's nothing to do
    if(tweets.length == 0) {
      return;
    }
       
    // grab a tweet
    tweet = tweets[0];
    // slice off the one we got
    tweets = tweets.slice(1);
       
    // push the delete button
    tweet.click();
    // wait 1000ms, hit modal button
    setTimeout(function() {
      $('.delete-action').click();
      // delete next one after 500ms
      setTimeout(function() {
        deleteTweet(tweets);
      }, 500);
    }, 1000);
    }
       
    // run the deletion function
    deleteTweet(buttonsOfTweetsToDelete);
   

6. Enjoy your tidy Twitter profile!
7. If you fixed the script, tell me how and I’ll update this post.

Posted by Jen Tong on February 5, 2018

I aspire to travel light. I can usually live out of a backpack. The Nintendo Switch is a recent addition to my kit. It’s heavy but totally worth the weight. Anything that adds 400 grams to my bag has to carry it’s weight, and the Switch delivers. Not only does it melt away those too-tired-to-code hours of airport delays, it turns out that the Joy-Con controllers make wonderful presentation remotes on MacOS!

Here’s how to turn a fun game controller into a boring slide clicker.

Ingredients

• A Nintendo Switch Joy-Con (I prefer the ergonomics of the right Joy-Con)
• USB Overdrive

Directions

1. Open System Preference -> Bluetooth on your laptop.

2. Hold the little pairing button down tiny pairing button on your Joy-Con for a few seconds. The lights might blink.

3. The Joy-Con will show up in the Bluetooth device list. Click through the strange pairing menu to pair it.

4. Open USB Overdrive, go to Status and verify that it sees the Joy-Con.
   

5. Switch back to the Settings tab. Press the buttons on the Joy-Con to see what they map to.

6. Pick a button to use for next slide, I used ZR. Map it to Press Key and use the select menu at the bottom choose to Page Down.
7. Pick a button for previous slide, and repeat the mapping but for Page Up. I used R.
8. Open your favorite slide program, and give it a spin. I’ve tested it for Keynote, Google Slides, reveal.js, and PDF decks opened in Preview.

When you’re done with slides and ready to game, slide the Joy-Con back on to your Switch. Once you turn the console on, it will re-pair the Joy-Con with the Switch and disconnect from your computer. You must re-pair it with your computer to click through slides again, but the USB Overdrive mapping should stick.

Was this entry useful? Did I say something wrong? Let me know on Twitter.

Posted by Jen Tong on January 3, 2018

Last week I had a rough day. Well, not really rough… mostly it just made me embarrassed to be a technologist. My role in this debacle was kind of fun.

I spent most of a day trying to get a video file off of a Samsung SDR-3100N DVR that’s hooked up to the security cameras at my condo. I managed to get the files off, and convert them into a usable format, but it was pretty painful. Here’s a writeup, just in case someone else has to deal with this mess.

Background

We’ve been using this Samsung SDR-3100N for years, but we haven’t ever had to access the video. Security cameras are a bit like disaster recovery. You don’t know if they work until you really need the video. Last week we needed the video.

Last week a couple of police officers knocked on our door. We learned that some jerkfaces broke into a bunch of bars near my house… on Christmas. It seems that they drove their vehicles past my condo’s security cameras, and the police wanted the video footage to aid in their investigation.

While they patiently watched, I attempted to access the video. The mobile app didn’t work. I grabbed a laptop. The Wifi access point didn’t work. I plugged into the switch with an Ethernet cable. The DHCP on the security camera’s network didn’t work. Plugging the laptop directly into the DVR and sniffed ARP traffic. There wasn’t any. It seems that entropy had set in and broken every piece of technology attached to the security cameras.

Not wanting to waste their time, I promised to send them the video files. We exchanged contact info, and my pretend forensics work began.

Using the DVR as intended

If you just want to get video off of your DVR, skip over this section. It was unsuccessful.

Attempt 1: The web interface

I unhooked the security DVR, plugged it into my working home network, and fired it up. It seemed OK. It booted with a harsh beep noise, and a green LED. I saw it get an IP address. It’s alive!

The mobile app connected and was able to see live video, but it could not find any previously recorded video.

The mobile app was pretty light in administrative features, so I could not investigate the root cause. But, it’s supposed to have a web interface. So, I typed its IP address into Chrome and gave it a poke. It demanded that I access it with IE or Safari (although the JavaScript it loaded seems to indicate that Firefox is also acceptable). I fired up Safari, and gave it another poke. A login page! And beyond that… a message that I need to install Microsoft Silverlight :(

But here’s the kicker, it wanted me to install an unsigned Silverlight binary delivered from the DVR itself.

I downloaded a signed Silverlight binary from Microsoft, but it still complained that I needed to install its fishy Silverlight binary. It turns out that Safari’s security settings disables Silverlight on all website by default. I enabled it for all websites by toggling ‘unsafe mode’, and gave it one more try.

This got me one step further. I was greeted by two loading spinners that displayed no content. This is where I stopped. I didn’t feel like reverse engineering their ancient web app. There has to be a more sensible way.

Attempt 2: Updating the firmware

Maybe the software is just too old for modern browsers. If that’s the case there has to be a firmware update, right? Nope. The Samsung support webpage does not even have a listing for this DVR, which they sold until 2013.

Poking around a bunch of forums didn’t turn up much either. As far as I can tell, they’ve never released any firmware updates for this product… ever. I couldn’t even find a mention of firmware updates in the paper instruction manual.

Attempt 3: Plug it into a monitor

The security DVR had spent its whole life in headless mode: it was never connected to a monitor. But it certainly has that capability. You can plug it into either a BNC composite display, or a VGA monitor to watch live feeds directly. This is perfect if you want to role-play one of those action movie scenes where a ninja knocks out security cameras one at a time while the security guard’s panic increases from dropped doughnut to spilled coffee. However, this option is not perfect for me. I have 0 display devices capable either VGA or BNC composite. But I do have a TV that can display RCA composite video. Rather than walk a block to buy an adapter, I hacked this up… and it worked!

When I carefully placed this delicate disaster near my TV, I could watch it boot up!

It was a dead end. After many minutes of booting up, it only displayed SAMSUNG across my TV in big letters. Fiddling with the remote control or a USB mouse didn’t do anything.

This is when I flipped form lawful neutral to chaotic neutral. It’s also when I reached for a screwdriver.

Getting at the video files some other way

I opened up the DVR and found a SATA hard disk inside. I plugged it into a USB write-blocker and connected it to my mac. diskutil reported it to be a Linux disk, but neither ext-fuse nor Paragon’s EXTfs driver could mount it. I’m not sure what’s up with that.

But I had another option: Kali linux on the laptop I took to DEFCON. And sure enough, it was able to read the disk. Oddly it had two partitions, both named NATALIE. The big NATALIE partition contained 500GB of video in ssf files all dated 2001. It seems that the real-time clock battery died at some point. The mobile app probably would have worked, if I had paged back to 2001. It’d be nice is the mobile app had told me that.

Anyway, I copied the files to another disk drive, this one formatted with exFAT so I could access them from my macOS laptop. Neither preview nor VLC were able to open the ssf files, but ffprobe displayed a lot of warnings and details about a single h264 video steam.

$  ffprobe 010404035310_000.ssf
... lots of warnings ...
Input #0, h264, from '010404035310_000.ssf':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (Constrained Baseline), yuv420p(progressive), 352x240, 25 fps, 25 tbr, 1200k tbn, 50 tbc

And ffmpeg was able to copy the stream to a more typical container.

$  ffmpeg -i ./010404035310_000.ssf -c copy 010404035310_000.mp4
... ~5000 lines of warnings ..
frame=513808 fps=48048 q=-1.0 Lsize= 1915044kB time=05:42:32.42 bitrate= 763.3kbits/s speed=1.92e+03x
video:1912815kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.116570%

Note the exponential notation on the speed. Aren’t modern disks wonderful?

And this resulting mp4 file works in VLC, but looks terribly corrupted. It seems that all of the video cameras have been smashed into a single h264 video stream, and players get really confused. It looks like compressed P-frames refer to the wrong complete I-frames. After trying a bunch of different video players and editors, Adobe Premier seems to read the video with the least corruption.

I tinkered around with ffmpeg but was unable to coerce it into reshuffling the frames. It didn’t like the idea of extracting a raw P-frame or attaching it to a different I-frame. But, you can remove the corruption by filtering out the confused P-frame references. You can use ffmpeg to pull out the I-frames (aka keyframes).

$ ffmpeg -i 010404035310_000.mp4 -vf select="eq(pict_type\,PICT_TYPE_I)" -vsync 0 iframe%03d.jpg
... cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1
frame=    4 fps=0.0 q=5.6 Lsize=N/A time=00:00:06.03 bitrate=N/A speed=16.8x
video:468kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

This yields a bunch of sharp jpg files. This is also where I stopped my analysis.

Conclusion

I was able to access the video, and review footage until I found what I was looking for. I also changed the real-time clock battery in the DVR, so the mobile app should work better now.

But, that was a pretty rough experience. I can’t imagine what a typical non-technical user would do, or even a technical user who didn’t have a day to kill tinkering with a broken-by-design security DVR. Samsung: shame on you.

I’d love to replace this DVR with something better, but all of the options I can find seem to suffer from the same terrible software and lack of updates. Now I understand why magic cloud cameras, like the Nest camera, are so appealing.