{"@attributes":{"version":"2.0"},"channel":{"title":"eta.st","description":"eta's personal website & blog\n","link":"https:\/\/eta.st\/","pubDate":"Mon, 15 Dec 2025 23:45:01 +0000","lastBuildDate":"Mon, 15 Dec 2025 23:45:01 +0000","generator":"Jekyll v4.3.4","item":[{"title":"Reversing UK mobile rail tickets","description":"

The UK has used small credit-card sized tickets to pay for train travel for years and years, since long before I was born \u2014 originally the\nAPTIS ticket<\/a>1<\/a><\/sup>,\nwhich later got replaced by a\nslightly easier to read version<\/a> printed onto the same stock.<\/p>\n\n

\"a<\/p>\n\n

Nowadays, the industry would very much like you to ditch your paper ticket in favour of a fancy mobile barcode one (or\nan ITSO<\/a> smartcard2<\/a><\/sup>); not\nonly do they not have to spend money on printing tickets but they also gain the ability to more precisely track the ticket\u2019s usage across the network\nand minimise fraud.<\/p>\n\n

\"promotional<\/p>\n\n

There are obvious benefits for the user too \u2014 I\u2019m willing to bet most people use the mobile tickets anyway, since they\u2019re just easier\nif you\u2019re booking your train travel in an app like Trainline<\/a>.<\/p>\n\n

But what data is inside the barcode of a mobile ticket, and how do they work? Could people who aren\u2019t ticket inspectors get the data out of them?\nIt turns out that the answer is a bit more interesting than I initially expected!<\/p>\n\n

Initial explorations<\/h2>\n\n

A mobile ticket is just an Aztec barcode<\/a>, either displayed inside an app or on a PDF you can print out:<\/p>\n\n

\"image<\/p>\n\n

Googling around for prior work people had done decoding mobile tickets, I found\na bunch of discussion<\/a> (German-language link) about UIC 918.3,\na specification used by the German railway company Deutsche Bahn for their e-tickets. These also use the Aztec barcode format and looked superficially\nsimilar \u2014 and some people had already written code to read them. Maybe this could work?<\/p>\n\n

(Why would I expect this to work? Well, the UIC is the international standards body for railways \u2014 in Europe at least \u2014\nso it\u2019s reasonable to assume they might\u2019ve used a standard format here.)<\/p>\n\n

However, the formats are sadly nothing alike \u2014 decoding our UK barcode using zxing<\/a>, we get:<\/p>\n\n

\n06DNQL4XHVK00TTRCGPUQWNTHPGHWBPOUTKRWXAJKGHFBAPBCTOGUZQVTZTKKDEBQXPGRWZJRJBXJZPOHNJGIPDJWEGYWJXLVPGEEZBCUUELIJMOINPRZMSDQCZJGLIZLUTQHXMTPKWCMJISUXQLORAOVYXSOLGXXGMVUDXTMHAYMBLUTKPUPFCRNNTDBBDLNWSBPDUXYKSIMJSBYBURSCPUMFBZPEUTECHTIOXAH\n<\/pre>\n\n
\u2026which looks nothing like you might expect a UIC barcode to look, given the latter are supposed to start with \u201c#UT\u201d\n(according to the discussion in German earlier).<\/p>\n\n
In fact, this is a custom standard that is only used inside the UK, as the \u201c06\u201d at the start of the data hints at; this is an \u201cRSP-6\u201d ticket\n(as in RSP for Rail Settlement Plan<\/a>), which Google doesn\u2019t seem to know much about.\nIt is possible to find a Freedom of Information Act request<\/a> someone made\nasking for the spec that never got a response \u2014 sadly the Rail Delivery Group (RDG), technically a private company, doesn\u2019t actually have to respond\nto such requests, so I\u2019d have to figure this out myself.<\/p>\n\n
A friendly wolf comes to help<\/h2>\n\n
At this point, I basically had no idea how to continue. Comparing multiple tickets, the data seemed to be mostly random apart from some fixed headers,\nsuggesting that it was probably encrypted in some way \u2014 I couldn\u2019t just get lots of tickets and hope to find similarities between them.<\/p>\n\n
\"photo<\/p>\n\n
image: output of binwalk -W cdq-cys.bin pad-aml.bin<\/code>, which highlights similarities and differences between two tickets3<\/a><\/sup><\/em><\/p>\n\n
My friend Harley (\u201cunlobito<\/a>\u201d) had noticed me complaining about tickets in a shared group chat and had a clue for me:\nthe word \u201cmasabi\u201d, which turned out to be the name of a ticketing company<\/a>.<\/p>\n\n
Masabi\u2019s website has this lovely page<\/a> where they explain all about how they invented mobile\nticketing in the UK in 2007 and how the RSP6 national standard was actually written by them! They also boast about how their\n\u201cJustRide Inspect\u201d suite of apps can be used to decode these tickets.<\/p>\n\n
\"Masabi<\/p>\n\n
We sadly can\u2019t just get this app off the Play Store. However, after some googling around you can totally get it from one of those less\nthan official APK rehosting websites.<\/p>\n\n
With the APK in hand there are a number of things we can do. We can just install it on an Android device and see whether it\u2019ll give up\nanything interesting that way; we can also try to \u201cdecompile\u201d it, to get a better idea of how the app (and the ticket parser) works.<\/p>\n\n
Running the app<\/h2>\n\n
Since I didn\u2019t have any spare throwaway Android phones and that the APK might be malware, my first step was to just run it\ninside an \nAndroid Virtual Device<\/a> (using the emulator in Android Studio).\nI reckoned this would be a bit safer than just installing it on my main Android phone.4<\/a><\/sup><\/p>\n\n
After a bit of fiddling about, I had it doing something:<\/p>\n\n
\"Inspect<\/p>\n\n
Unfortunately, this wasn\u2019t very useful \u2014 it wouldn\u2019t scan standard ticket barcodes in this form. The \u201cLogin manually\u201d button lets you\nchoose a Train Operating Company (TOC) to sign in as (some of the companies mentioned don\u2019t even exist any more!), which was pretty\ninteresting but not useful for our goals:<\/p>\n\n
\"Inspect<\/p>\n\n
I don\u2019t work for a train operating company, so clearly it wasn\u2019t going to be possible for me to proceed5<\/a><\/sup>.\nMaybe examining the app another way could get us somewhere?<\/p>\n\n
Decompiling the app<\/h2>\n\n
You can point Android Studio at an APK and have it analyse what\u2019s inside. Sort of.<\/p>\n\n
If you try this (via the 3-dot menu in the project chooser \u2192 \u201cProfile or Debug APK\u201d), you get something that\u2019s not entirely useful:\na bunch of weird looking \u201csmali\u201d files.<\/p>\n\n
\"Android<\/p>\n\n
This is because the APK only contains compiled bytecode, rather than any useful source code; as the yellow warning banner notes,\nthis is stored inside the APK in .dex format<\/a>\n(\u201cDalvik Executable\u201d, where Dalvik is the name of the Android VM), and\nsmali<\/a> is just a human-readable representation someone invented for this format (like Assembly).<\/p>\n\n
What we ideally need is something that can turn the bytecode all the way back into Java. Such a tool exists in the form of\njadx<\/a>, a very handy tool that not only does just that, but can also do a bunch of other\ncool stuff like outputting a project Android Studio can load (and theoretically compile)!<\/p>\n\n
\n$ jadx --deobf -e -d out ~\/Downloads\/justride-inspect.apk\nINFO  - loading ...\nINFO  - processing ...\nINFO  - done                                                 \n$ ls out\/\napp  build.gradle  settings.gradle\n<\/pre>\n\n
Making sense of the decompiled output<\/h2>\n\n
When I looked in jadx\u2019s output directory I found a perfect copy of the original source code that Masabi had written,\nand my job was then very easy. Wait, no, that\u2019s a lie.<\/p>\n\n
Before shipping an APK to the end user, Android app developers usually run it through a number of steps to make it smaller\nincluding \u201cobfuscation\u201d \u2014 turning long class and member names like \u201cmContext\u201d into the smallest string they can get away with, like \u201ca\u201d.\nThis means that the code jadx generated is rather hard to make sense of:<\/p>\n\n
public<\/span> class<\/span> TicketInspectActivity<\/span> extends<\/span> BaseActivity<\/span> implements<\/span> InterfaceC2526a<\/span> {<\/span>\n\n   \/* renamed from: c *\/<\/span>\n   private<\/span> ViewPager<\/span> f4615c<\/span>;<\/span>\n\n   \/* JADX INFO: Access modifiers changed from: private *\/<\/span>\n   \/* renamed from: h *\/<\/span>\n   public<\/span> C2496p<\/span> m1419h<\/span>()<\/span> {<\/span>\n       return<\/span> (<\/span>C2496p<\/span>)<\/span> this<\/span>.<\/span>f4615c<\/span>.<\/span>getAdapter<\/span>();<\/span>\n   }<\/span>\n\n   @Override<\/span> \/\/ com.masabi.app.android.ticketcheck.activities.BaseActivity<\/span>\n   \/* renamed from: a *\/<\/span>\n   public<\/span> final<\/span> void<\/span> mo1410a<\/span>()<\/span> {<\/span>\n       super<\/span>.<\/span>mo1410a<\/span>();<\/span>\n       if<\/span> (<\/span>isFinishing<\/span>())<\/span> {<\/span>\n           return<\/span>;<\/span>\n       }<\/span>\n       m1419h<\/span>().<\/span>m1467a<\/span>(<\/span>this<\/span>.<\/span>f4615c<\/span>.<\/span>getCurrentItem<\/span>());<\/span>\n   }<\/span>\n   \/* ... *\/<\/span>\n}<\/span><\/code><\/pre><\/figure>\n\n
Despite this looking daunting at first it\u2019s actually quite okay with the tools Android Studio gives us. Not everything is completely obfuscated:\nsome class names need to be left deobfuscated, such as activities (like this TicketInspectActivity<\/code>). That lets us get some idea of\nwhere to start. The code also occasionally contains error messages that give away what the classes and methods are supposed to be:<\/p>\n\n
\/* renamed from: com.masabi.c.a *\/<\/span>\n\/* loaded from: classes.dex *\/<\/span>\npublic<\/span> final<\/span> class<\/span> C2666a<\/span> {<\/span>\n   \/* renamed from: a *\/<\/span>\n   public<\/span> static<\/span> final<\/span> int<\/span> m552a<\/span>(<\/span>Calendar<\/span> calendar<\/span>)<\/span> {<\/span>\n       if<\/span> (<\/span>calendar<\/span> ==<\/span> null<\/span>)<\/span> {<\/span>\n           System<\/span>.<\/span>err<\/span>.<\/span>println<\/span>(<\/span>\"DateTimeUtils.packDate() ERROR - Attempt to pack a null date!\"<\/span>);<\/span>\n       }<\/span>\n       return<\/span> (<\/span>C2668c<\/span>.<\/span>m542a<\/span>(<\/span>calendar<\/span>)<\/span> <<<\/span> 16<\/span>)<\/span> |<\/span> (<\/span>C2667b<\/span>.<\/span>m548a<\/span>(<\/span>calendar<\/span>)<\/span> &<\/span> 65535<\/span>);<\/span>\n   }<\/span>\n   \/* ... *\/<\/span>\n}<\/span><\/code><\/pre><\/figure>\n\n
In this case, the log line lets us instantly rename C2666a<\/code> \u2192 DateTimeUtils<\/code>, and m552a<\/code> \u2192 packDate<\/code>.<\/p>\n\n
\"the<\/p>\n\n
Interesting uses of RSA<\/h2>\n\n
My investigations into the app confirmed my suspicions that the data was indeed encrypted \u2014 well, not quite. Technically, the ticket data\nis actually signed<\/em> with RSA and PKCS#1<\/a> (I think). Ticket issuers generate a payload containing the\nticket data, pad it a bit, and then use their RSA private key to create a signed message they put into the barcode. A ticket scanner has a set\nof the issuers\u2019 public keys on hand to verify the signature and read the original payload.<\/p>\n\n
As a more concrete example, some vague Rust code to do the verification and reading steps looks a bit like this:<\/p>\n\n
\/\/ BigUint is an arbitrary size unsigned integer.<\/span>\n\/\/ The ticket is base26 encoded, so we need to undo that first:<\/span>\nlet<\/span> ticket<\/span>:<\/span> BigUint<\/span> =<\/span> base26_decode<\/span>(<\/span>&<\/span>ticket_str<\/span>[<\/span>15<\/span>..<\/span>]);<\/span>\n\/\/ this is doing \u201cS^e mod N\u201d;<\/span>\n\/\/ i.e. part of RSA signature verification<\/span>\nlet<\/span> message<\/span> =<\/span> ticket<\/span>.modpow<\/span>(<\/span>&<\/span>key<\/span>.public_exponent<\/span>,<\/span> &<\/span>key<\/span>.modulus<\/span>);<\/span>\n\/\/ convert big integer into raw bytes (big-endian)<\/span>\nlet<\/span> message<\/span>:<\/span> Vec<\/span><<\/span>u8<\/span>><\/span> =<\/span> message<\/span>.to_bytes_be<\/span>();<\/span>\n\/\/ attempt to strip PKCS#1 padding; if it fails, the key is wrong<\/span>\nif<\/span> let<\/span> Some<\/span>(<\/span>unpadded<\/span>)<\/span> =<\/span> strip_padding<\/span>(<\/span>&<\/span>message<\/span>)<\/span> {<\/span>\n   eprintln!<\/span>(<\/span>\"[+] decrypt done: {:?}\"<\/span>,<\/span> unpadded<\/span>);<\/span>\n}<\/span><\/code><\/pre><\/figure>\n\n
You also can\u2019t make your own fraudulent tickets using this scheme; you\u2019d need the RSA private key of one of the ticket issuers to do that,\nor to have a custom public key added to the network of gate readers and ticket inspectors\u2019 apps, neither of which seem easy to do.<\/p>\n\n
\nSome further details on the cryptography (click to expand)<\/summary>\n
\n
How can you tell that the ticket payload was unwrapped correctly? The payload is padded in a way that I think corresponds to some of the\nalgorithms in PKCS#1 (see RFC 8017<\/a>); it'll either be<\/p>\n\n
\nScheme 1: padded = [0x00, 0x01, padding-string, 0x00, message]<\/code>
\n(where padding-string<\/code> is a length of 0xFF<\/code> octets)\n<\/p>\n\n
\nor\n<\/p>\n\n
\nScheme 2: padded = [0x00, 0x02, padding-string, 0x00, message]<\/code>
\n(where padding-string<\/code> is a length of random non zero octets)\n<\/p>\n\n
If the payload doesn't look like either of these, the RSA operation failed, so you probably have the wrong key and should try another one.<\/p>\n<\/div>\n<\/details>\n\n
So the public keys are required knowledge for actually being able to decode these tickets. Where do we get those from?<\/p>\n\n
Obtaining the elusive public keys<\/h2>\n\n
The public keys aren\u2019t really published anywhere obvious, and reversing the Masabi app seems to indicate that it downloads the keys from a\nconfiguration server once you scan the config barcode mentioned earlier.<\/p>\n\n
Global<\/span>.<\/span>logger<\/span>.<\/span>log<\/span>(<\/span>getClass<\/span>().<\/span>getSimpleName<\/span>(),<\/span> \"loadAllKeys() - Fetched \"<\/span> +<\/span> barcodeKeysList<\/span>.<\/span>length<\/span> +<\/span> \" barcode keys from metadata\"<\/span>);<\/span>\nfor<\/span> (<\/span>int<\/span> i<\/span> =<\/span> 0<\/span>;<\/span> i<\/span> <<\/span> barcodeKeysList<\/span>.<\/span>length<\/span>;<\/span> i<\/span>++)<\/span> {<\/span>\n   AbstractJSONObject<\/span> key<\/span> =<\/span> (<\/span>barcodeKeysList<\/span>[<\/span>i2<\/span>];<\/span>\n   if<\/span> (<\/span>ExtendedGlobal2<\/span>.<\/span>clock<\/span>.<\/span>getCurrentTime<\/span>()<\/span> <<\/span> Global<\/span>.<\/span>f4949d<\/span>.<\/span>mo915a<\/span>(<\/span>key<\/span>.<\/span>getString<\/span>(<\/span>\"expiryDate\"<\/span>))<\/span> *<\/span> 1000<\/span> &&<\/span>\n           (<\/span>decoder<\/span> =<\/span> makeDecoder<\/span>(<\/span>key<\/span>.<\/span>getString<\/span>(<\/span>\"issuerId\"<\/span>),<\/span> key<\/span>.<\/span>getString<\/span>(<\/span>\"ticketType\"<\/span>),<\/span> key<\/span>.<\/span>getString<\/span>(<\/span>\"modulus\"<\/span>),<\/span> key<\/span>.<\/span>getString<\/span>(<\/span>\"exponent\"<\/span>),<\/span> key<\/span>.<\/span>getLong<\/span>(<\/span>\"mQ\"<\/span>)))<\/span> !=<\/span> null<\/span>)<\/span> {<\/span>\n       decoders<\/span>.<\/span>addElement<\/span>(<\/span>decoder<\/span>);<\/span>\n   }<\/span>\n}<\/span><\/code><\/pre><\/figure>\n\n
You\u2019d think this would be a dead end, since we don\u2019t have any login credentials \u2014 but they also just left some keys inside the APK\nas well. As far as I can tell no part of the app actually reads these; maybe it did in the past, or maybe they used them for testing and\nforgot to take them out of the production version of the app.<\/p>\n\n
\n$ find . | grep 'keys' | grep rsp6\n.\/app\/src\/main\/assets\/keys\/rsp6_rsa_ao.dat\n.\/app\/src\/main\/assets\/keys\/rsp6_rsa_ua.dat\n.\/app\/src\/main\/assets\/keys\/rsp6_rsa_tt-qa.dat\n.\/app\/src\/main\/assets\/keys\/rsp6_rsa_tt.dat\n.\/app\/src\/main\/assets\/keys\/rsp6_rsa_t3.dat\n.\/app\/src\/main\/assets\/keys\/rsp6_rsa_t2.dat\n<\/pre>\n\n
The keys are split up by ticket issuer, a 2-character code that forms the first part of the ticket ID. This ticket from earlier was issued\nby Trainline, who have issuer code TT<\/strong>\u2026<\/p>\n\n
\"barcode<\/p>\n\n
\u2026and the keys to decode this ticket are in rsp6_rsa_tt<\/b>.dat<\/code>. Nice!8<\/a><\/sup><\/p>\n\n
This is only a subset of all the keys that are being used today though, as I quickly discovered when\nunlobito<\/a> gave me an Avanti West Coast<\/a> ticket to decode.\nThe copy of the app I have is only from 2016 and a bunch more TOCs have started issuing mobile tickets since then!<\/p>\n\n
ttkMobile<\/h2>\n\n
Around when I was figuring all of this out puck<\/a> pointed me towards the website for\nThe Ticket Keeper<\/a>, another firm who makes ticket validation and issuance tooling.\nThey have an iOS app for ticket inspectors called ttkMobile<\/strong>, which you can just\ndownload straight off the App Store<\/a> and use to start validating tickets at home!9<\/a><\/sup><\/p>\n\n
\"screenshot<\/p>\n\n
\nImportant note if you actually intend to use this app (click to expand)<\/summary>\n
Be warned!<\/p>\n\n
If you install this app, you can\u2019t ever uninstall it and expect it to work after a reinstall.\nOn first load it registers your device UUID with some server and generates a random password that it stores in local storage.\nUninstalling the app removes the password, but your device UUID doesn\u2019t change, so next time you reinstall, it won\u2019t be able\nto authenticate and it\u2019ll be useless (since it needs to grab keys and stuff to work).<\/p>\n\n
(\u201cBut wait,\u201d I hear you cry, \u201cisn\u2019t getting a persistent device ID exactly what Apple don\u2019t want you to do?\u201d And you\u2019d be right! Technically, I believe\nthe device UUID actually does<\/i> change between installs, but they store a copy in the device keychain, which doesn\u2019t get wiped\nwhen you remove the app. This is stupid, and almost certainly a contravention of App Store policy.)<\/p>\n<\/details>\n\n
I don\u2019t have an iPhone, but some of my friends do. unlobito and another friend,\nEva (\u201cthejsa<\/a>\u201d), had a poke around and managed to get me a DRM-free10<\/a><\/sup> .ipa<\/code><\/a>\ncontaining the app, which I could unwrap and decompile with the help of Ghidra<\/a>.\nThis let me figure out some of the pieces of the ticket that the Masabi app didn\u2019t look at.<\/p>\n\n
thejsa<\/a> also spent some time running the app through a proxy in order to find out how it\ncommunicates with the server11<\/a><\/sup>, and it turns out there\u2019s just an endpoint where you can get all of the public keys:<\/p>\n\n
\n$ curl 'https:\/\/device.theticketkeeper.com\/download_keys?device_name=abc' | jq .\n{\n  \"return_code\": \"ok\",\n  \"message\": null,\n  \"keys\": {\n    \"AA\": [\n      {\n        \"valid_from\": \"20000101000000\",\n        \"valid_until\": \"29991231000000\",\n        \"public_exponent_hex\": \"10001\",\n        \"modulus_hex\": \"9140AA61F7D9A2E943C0510BACA5FA9CA7D12D78E301A36D640F2D28D8C0AA4D6A7102555CECF138E467730B797509EC1AB5BBA77CA6384BC8F483F609B121E75AE42660EDFE15EF91ADD4DA68C355F830FAAC6FFB25FBCFE1E61C7AF37C4AE8C85E264C151BD9C9AA4DE41D2756A9E260C0CC89AE2ADDD19E452A675E88DA47\",\n        \"public_key_x509\": null,\n        \"test_only\": \"N\",\n        \"updated\": \"20200313175331\"\n      },\n[etc]\n<\/pre>\n\n
As I mentioned earlier, this is crucial information to be able to decode tickets at all,\nso thanks go to The Ticket Keeper developers for making it available so easily!<\/p>\n\n
Brief aside on freedom of information<\/h3>\n\n
I don\u2019t know whether people in the industry (e.g. the Rail Delivery Group)\nwill be upset with me publishing this information or not.\nI hope they won\u2019t be: I really think the public keys should be made available to the public, along with the official specifications for decoding.\nThe tickets are signed, so it\u2019s not as if there\u2019s any practical danger \u2014 people can\u2019t use this to start forging tickets en masse, for example \u2014\nand there are lots of potential innovative uses for this data. Imagine for example a journey logger that used ticket scans to track where you\u2019d\nbeen automatically, or an expenses system that used the price information encoded in the ticket to automatically log expense requests!<\/p>\n\n
The railways might be run by a consortium of private companies, but they are in effect a public service owned and controlled\nby the Government12<\/a><\/sup> (as of Jan 2023), so they really should be subject to the same Freedom of Information Act provisions as other public bodies.<\/p>\n\n
Some people in the industry already have the right idea; in conversation with one of the Ticket Keeper developers over email,\nI was made aware that the ttkMobile app being public along with some of this data is actually an intentional choice, which is really nice to see!<\/p>\n\n
Bonus: eTVD logs<\/h3>\n\n
The website also tells you how they have an electronic Ticket Validation Database (eTVD<\/a>)\nthat has a copy of all ticket scans at gatelines and by people using their app. This is the anti-fraud thing I mentioned at the very start; this sort\nof data is presumably very useful to revenue protection staff trying to figure out systematic fare evasion, like short-faring13<\/a><\/sup>.<\/p>\n\n
What it doesn\u2019t tell you, though, is that the app will also give you this information unauthenticated, with nothing more than a ticket\u2019s ID (!).<\/p>\n\n
\nThis was reported to the developers as a possible security issue \/ data leak on 2023-01-19. They confirmed it was intended behaviour, but\nagreed that it would probably be a good idea to restrict it; I'm told this will happen soon.\n<\/div>\n\n
This information can be quite disturbingly detailed, even pinpointing the exact username of the inspector who scanned you,\nwhere you were scanned, on what exact train service you were scanned, whether it succeeded, and a bunch more stuff.\nHelpfully it\u2019ll also sometimes give you the entire barcode data, and what the ticket server thinks it decodes as, too!<\/p>\n\n
\n# getting scan history information for ticket CBCZSCDPVFF\n# (this is massively cut down; there are more fields in reality)\n$ curl 'https:\/\/device.theticketkeeper.com\/get_ticket_details?device_name=abc&utn=CBCZSCDPVFF' | jq '.[\"ticket_detail\"][\"scans\"]'\n[\n  {\n    \"event_time_iso\": \"2022-06-10T18:30:47\",\n    \"created\": \"2022-06-10T18:30:48\",\n    \"device_type\": \"ttkMobile\",\n    \"device_id\": 1001,\n    \"device_name\": \"f95396f5-da22-47f9-8e85-dff4b2294a5d\",\n    \"device_alias\": \"2021-TK10212\",\n    \"username\": \"JLazlo01\",\n    \"action_name\": \"Accepted\",\n    \"rsp_action_code\": 4001,\n    \"event_trigger\": \"scan\",\n    \"scan_mode\": \"clip\",\n    \"scan_nlc\": \"2728\",\n    \"validation_result\": \"warning\",\n    \"message_displayed\": \"16-25 Railcard\",\n    \"gate_id\": \"OPN-3002i[021502]\",\n    \"latitude\": 51.7824963,\n    \"longitude\": -0.2141781,\n    \"device_scan_id\": 74402,\n    \"train_uid\": \"L77572\",\n    \"departure_date\": \"2022-06-10\",\n    \"barcode\": \"06CZSCDPVFF00\u2026\",\n    \"train_info\": \"Fr1803 KGX-SKI 1D26\/GR2600\",\n    # etc\n  },\n  # etc\n]\n<\/pre>\n\n
So yeah, your ticket barcode \u2014 or its ID, which is often written below the code in plain text \u2014\nmight let someone access a surprising amount of detailed tracking information as to where you are and what trains you\u2019re taking!\n(Rather like\nthe booking reference they send you when you book a flight<\/a>.)<\/p>\n\n
Trying this out for yourself<\/h2>\n\n
With the decompiled Masabi app and the ttkMobile app together, it wasn\u2019t too hard to work out a vague idea of what the ticket format\nwas like. I\u2019ve put together a small repository<\/a> with a Rust tool to decode a ticket,\nas well as a small spec with my best guess on what all the fields mean.<\/p>\n\n
There\u2019s also a funky web tool<\/a> I threw together in an evening or so that\u2019ll let you point your phone at\na barcode (or upload a screenshot of one) and give you a relatively nice readout of what data\u2019s inside.\nGive it a try!<\/a> (If you need a barcode, feel free to scroll up and use the one from this post!)<\/p>\n\n
Do feel free to get in touch<\/a> if you find anything interesting or need help understanding something about the format!<\/p>\n\n
Acknowledgements<\/h2>\n\n
Thanks to unlobito<\/a>, puck<\/a>, and thejsa<\/a> (and assorted others\nin various chatrooms) for their help with all of this; go check those people out, too!<\/p>\n\n
\n\n
Footnotes<\/h3>\n\n
\n  
    \n    
  1. \n      
    I still have fond memories of getting these as a child for local journeys to London Waterloo!\u00a0↩<\/a><\/p>\n    <\/li>\n    
  2. \n      
    This talk<\/a> is a decent overview of the mess that is ITSO, if you\u2019re interested.\u00a0↩<\/a><\/p>\n    <\/li>\n    
  3. \n      
    I did try with more than just two tickets, but that\u2019d make for an unwieldy image.\u00a0↩<\/a><\/p>\n    <\/li>\n    
  4. \n      
    A VM provides a decent<\/em> level of protection against running untrusted code, but it\u2019s not the end-all and be-all;\n    I\u2019d imagine the Android emulator isn\u2019t exactly hardened against people trying to break out, so this probably isn\u2019t a\n    bulletproof strategy for running shady apps in the general case.\u00a0↩<\/a><\/p>\n    <\/li>\n    
  5. \n      
    It turns out that the app actually downloads a lot of the keys and data necessary to decode tickets using this login,\n      so even if I could somehow glitch it into starting the main ticket scanner, it wouldn\u2019t have worked.\u00a0↩<\/a><\/p>\n    <\/li>\n    
  6. \n      
    jadx has made things slightly easier for us by renaming some identifiers (\u201cdeobfuscation\u201d): adding some numbers and adding\n     prefixes like \u201cC\u201d for \u201cclass\u201d that help us distinguish amongst the multitude of things called \u201ca\u201d or \u201cb\u201d.\u00a0↩<\/a><\/p>\n    <\/li>\n    
  7. \n      
    It\u2019s impossible to know without the real source what all the classes were actually called, but I can give them names that\n        make sense to me<\/em>, and that\u2019s all that matters really. puck actually did manage to find an app that used some classes from\n        the Masabi SDK that was not obfuscated later on, which let me compare and see how accurate my invented names were against\n        the real ones!\u00a0↩<\/a><\/p>\n    <\/li>\n    
  8. \n      
    The format of these .dat files is a bit weird and nonstandard, and you have to reverse the RSA decryption code to figure out\n        what it is. Or, you can be lazy like me, and just paste the decompiled code into a new Java project and treat it as a black box.\u00a0↩<\/a><\/p>\n    <\/li>\n    
  9. \n      
    It does expect to report back completed ticket scans by default, so you have to futz around and listen to it complain a bit before it\u2019ll work.\n    Also, the \u201cTicket Issuing\u201d button doesn\u2019t work, if you were wondering; you need a login for that.\u00a0↩<\/a><\/p>\n    <\/li>\n    
  10. \n      
    As I understand it, you usually need a jailbroken phone to do this. Otherwise, you could just copy paid apps between phones and\n      share them with people who hadn\u2019t paid for them.\u00a0↩<\/a><\/p>\n    <\/li>\n    
  11. \n      
    This is also how she discovered the reason why the app doesn\u2019t work after being uninstalled. She even went so far as writing\n       a jailbreak tweak to change the device ID to make it work again, which is pretty cool!\u00a0↩<\/a><\/p>\n    <\/li>\n    
  12. \n      
    Yes, our railway looks privatised on the surface, but COVID actually resulted in so-called\n     Emergency Recovery Measures Agreements<\/a>\n     that forced the TOCs into effective state ownership and control (they\u2019re now in effect contractors who run the service, rather than\n     taking revenue risk). This means that the Government are actually responsible for things like the\n     current union dispute over jobs and working conditions, despite what some ministers would have you think!\u00a0↩<\/a><\/p>\n    <\/li>\n    
  13. \n      
    This refers to the practice of buying a ticket that doesn\u2019t actually cover your whole journey (e.g. skipping some stops at the start or\n          end), and gambling that you\u2019ll only get inspected between the stations where it\u2019s actually valid.\u00a0↩<\/a><\/p>\n    <\/li>\n  <\/ol>\n<\/div>\n","pubDate":"Tue, 31 Jan 2023 00:00:00 +0000","link":"https:\/\/eta.st\/2023\/01\/31\/rail-tickets.html","guid":"https:\/\/eta.st\/2023\/01\/31\/rail-tickets.html"},{"title":"Pessimism is a bad defense mechanism","description":"
    \nWarning!<\/b> This post is a mental health \/ feels post from a long time ago (in fact, one gender ago<\/a>).\nIt is kept up in case some people find it useful, but I don't necessarily endorse the content in here nowadays.\n<\/div>\n\n
    Why do some people have poor mental health? It\u2019s hard to know \u2013 there\u2019s an entire profession centred on answering this question! \u2013 but I feel like a part\nof it has to do with doing things that sabotage oneself, without necessarily being aware of the fact that this is happening. Of course, the next question\nis inevitably why people even begin to do such things; surely if sabotaging yourself leads to bad mental health, people would just not do it, and therefore\nlead happier lives.<\/p>\n\n
    \n\n
    When you\u2019ve had a history of things not going too well, it can often be difficult to accept that a situation is actually pretty great \u2013 because doing so\ninvolves accepting the idea that things might turn out to be not so great later on, which is painful, so doing so puts you in a vulnerable position.\nSome might argue this is silly, and you should just accept the risk and enjoy the benefits of the situation \u2013 but this all depends on how things have gone\ndown in the past. If you\u2019ve opened yourself up and had a bad time, you\u2019re probably going to be inclined to avoid showing vulnerability in future.<\/p>\n\n
    Taking the avoidance of vulnerability to its extremes often involves a heavy degree of pessimism. If you judge everything to be terrible even when it isn\u2019t,\nyou can conveniently avoid feeling bad about stuff going wrong; you already mentally prepared yourself for this outcome anyway, so there\u2019s no loss. And if\nit goes well, that\u2019s a bonus! The events in the past that hurt you because you opened yourself up and showed vulnerability can\u2019t any more; there\u2019s a far\nsmaller gap between your expectation and the reality if the reality does turn out to be bad.<\/p>\n\n
    As the title of this post says, this is a defence mechanism. I can definitely recall times when something hurt me, often to such an extent that I felt a\nneed to burst out in tears (usually in some inopportune place, like on public transport) \u2013 but I didn\u2019t; I clenched my teeth, and muttered something\nunder my breath about the person who had hurt me being terrible all along, or the situation being doomed from the start, or some other overly-negative\nview that would manage to make the pain hurt less, somehow. Or, if it couldn\u2019t do that, it would at least keep me from visibly crying in front of all\nthe other commuters on the train.<\/p>\n\n
    \n\n
    Side note: what even happens if you cry on a train, just in front of people? Do people look at you like some sort of insane person and just let you get\non with it in peace? Do complete strangers ask you if you\u2019re alright? Maybe it isn\u2019t actually too terrible \u2013 or maybe it\u2019s really rude. Will I ever\nfind out?<\/p>\n\n
    For one reason or another1<\/a><\/sup>, I grew up with the idea that showing weakness is bad. To this day, it\u2019s something that I find very difficult to do, and I\noften criticize myself for having done it. We all need to show weakness eventually, though; sometimes things just get way too much to bear, and it all\ncomes flooding out. Unfortunately, this can perpetuate a vicious cycle: the only occasions where you open yourself up are hysterical disasters where\nyou end up paragraphing<\/a> one of your friends about all of your problems at once, or having\na lengthy phone call where you\u2019re the only one talking for a solid hour. This seems like a really imposing and terrible thing to do to people, so you\nconclude that showing weakness is bad, so you don\u2019t do it as much\u2026 meaning the outburst is even worse next time, because you can\u2019t hold the feelings\nback forever.<\/p>\n\n
    But when you\u2019re trapped in the above cycle, it\u2019s incredibly tempting to just push the inevitable feelings outburst forward by a few days\/weeks\/months with the\nliberal application of some pessimism.<\/p>\n\n
    \n\n
    Apart from this train-crying-reduction purpose, the other thing pessimism is very good at is making the actual causes of things far more vague and\nnebulous. You can avoid thinking about why something went wrong if you chalk the whole thing up to it just being a bad situation; this is particularly\nuseful when you\u2019re actually the one doing things to make a situation worse. Here\u2019s an example2<\/a><\/sup>: maybe you\u2019re sad about getting out of contact\nwith a friend you haven\u2019t seen in a while. If you take a pessimistic angle, you can usefully assume this is because people just naturally drift apart given\nspace, which is unfortunate but makes the whole thing seem rather impersonal: it\u2019s just a thing which is happening to you which you have no control over.<\/p>\n\n
    This isn\u2019t how it works, though \u2013 in the above situation, the reason why you don\u2019t talk to the friend could actually be because you<\/em> don\u2019t make much\nof an effort any more with them, because of the pessimism (\u201cwe\u2019re going to drift apart anyway\u201d). Another example: maybe you\u2019re upset about being fired,\napply for a new job, and don\u2019t get it. In a lot of situations, you do indeed have no control over whether or not the company will hire you \u2013 but\nif you thought you\u2019d never get a job again after getting fired and didn\u2019t bother to put in the effort for the application as a result, you\u2019re actually\nsabotaging yourself here.<\/p>\n\n
    This ability of pessimism to confuse situations can start to ruin your life if you\u2019re not careful. If everything is terrible, what\u2019s the point in doing\nanything? Opportunities to make things better pass you by without you doing anything (because you refuse to be brave enough to actually take things\ninto your own hands and maybe fail), and can then serve as further examples of why everything is terrible when you start feeling bad about what you\u2019ve\nmissed out on, reinforcing the cycle. Because it\u2019s not always obvious that you<\/em> were the one that made the situation bad, you\u2019re left feeling like\nyou can\u2019t do anything about it. Even when it\u2019s clear that you made a mistake, you might view yourself as incontrovertibly bad \u2013 sure, it was your\nfault, but you\u2019re a terrible person, so you\u2019d never have made the right decision anyway (!).<\/p>\n\n
    Thinking like this leads to viewing life as this third-person experience where stuff just happens to you and you have to just sit there and take it \u2013\nthat you have no control over events. (Some people call this \u201clearned helplessness\u201d<\/a>.)\nAnd that\u2019s, to put it mildly, not good; you can get very depressed3<\/a><\/sup> this way!<\/p>\n\n
    \n\n
    I would have liked to finish this blog post with some inspiring call to action about how to get out of this cycle and make all the things better in 3\nsimple steps. Unfortunately, I\u2019m not actually qualified enough to do that.<\/p>\n\n
    Knowing what a problem is is often half the battle, however, and it\u2019s definitely possible to use this knowledge for good. The research on learned\nhelplessness actually suggests that it\u2019s not helplessness people learn, it\u2019s actually helpful<\/em>ness \u2013 the default opinion of the brain is (allegedly)\nthat you can\u2019t do things to change your situation, and you have to teach<\/em> it that you do actually have some power after all.<\/p>\n\n
    So, do some things, and pay attention to their effect. I bet at least in some cases, you have more ability to change things than you think.<\/p>\n\n
    \n\n
    \n  
      \n    
    1. \n      
      Is going to a academically selective, all-male private school a reason? No, that couldn\u2019t possibly<\/em> be related\u2026\u00a0↩<\/a><\/p>\n    <\/li>\n    
    2. \n      
      Frequent readers of the blog will know that the \u201cexamples\u201d are often sanitized versions of things that have recently happened.\u00a0↩<\/a><\/p>\n    <\/li>\n    
    3. \n      
      I think it\u2019s actually a lot more<\/em> dangerous when you hold this belief underneath, but otherwise have what seems to be a relatively okay life.\n  Every so often, something will happen that makes you sad for a while, and then you\u2019ll get over it and act like nothing happened without realizing\n  what\u2019s going on \u2013 thereby ensuring that you\u2019ll continue to become occasionally sad in perpetuity!\u00a0↩<\/a><\/p>\n    <\/li>\n  <\/ol>\n<\/div>\n","pubDate":"Wed, 30 Jun 2021 00:00:00 +0000","link":"https:\/\/eta.st\/2021\/06\/30\/self-sabotage.html","guid":"https:\/\/eta.st\/2021\/06\/30\/self-sabotage.html"},{"title":"Sending audio to LKV373 HDMI extenders","description":"
      My current flatmate<\/a> has a bunch of these HDMI extender devices<\/a>\n(also apparently known as \u201cLKV373\u201d \/ \u201cLenkeng extenders\u201d \/ \u201cLK-3080-ACL\u201d). They\u2019re pretty nifty: HDMI goes in one end, they emit UDP over ethernet,\nand then HDMI comes out on the receiver end with surprisingly minimal latency (around 100ms).<\/p>\n\n
      \"photo<\/p>\n\n
      image: the receiver end of a transmitter-receiver pair, taken by said flatmate<\/em><\/p>\n\n
      A couple months ago we decided it\u2019d be quite nifty to be able to play arbitrary audio out of the devices without having to plug a transmitter into someone\u2019s\nlaptop \u2013 so that we could have BBC Radio 4 or something constantly playing whenever the sound system is turned on.<\/p>\n\n
      My flatmate\u2019s blog post, \u201cLudicrously cheap HDMI capture for Linux\u201d<\/a>, outlined a way to\ndecode<\/em> the signal the transmitters sent (using his own tool, \nde-ip-hdmi<\/code><\/a>). But could we do the opposite,\nand encode<\/em> signals the receivers would accept?<\/p>\n\n
      Testing without the actual devices<\/h2>\n\n
      I figured I\u2019d start by looking at de-ip-hdmi<\/code>\u2019s source code to see how it\ndecoded the packets and then use it as a way to test the output of my\ncustom sender until it was able to decode what I was sending. It\u2019s pretty\nunlikely that I\u2019d just be able to send audio without also sending a picture,\nso I tried to figure out the picture format first.<\/p>\n\n
      \"video<\/p>\n\n
      The video picture packets have a fairly simple format: two big-endian, 16-bit\nintegers (frame number, and sequence number), and then data, up to 1020 bytes\n(making UDP packets with a 1024-byte payload, total).<\/p>\n\n
      Extracting the output from de-ip-hdmi<\/code> with a transmitter running\nconfirms that the data is just a JPEG:<\/p>\n\n
      $ file test.mjpeg \ntest.mjpeg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 1920x1080, components 3\n<\/code><\/pre><\/div><\/div>\n\n
      The frame number counts\nmonotonically up from 0, incrementing with each new frame. Since you\u2019re not\ngoing to fit a whole JPEG frame in 1020 bytes, the sequence number provides a way of\nsplitting the frame up into multiple chunks; you increment it for each chunk\nyou send within a frame, while keeping the frame number constant.<\/p>\n\n
      The de-ip-hdmi<\/code> source code to decode<\/a>\nlooks like this:<\/p>\n\n
      \/\/ taken from the de-ip-hdmi source code, in Go<\/span>\nFrameNumber<\/span> :=<\/span> uint16<\/span>(<\/span>0<\/span>)<\/span>\nCurrentChunk<\/span> :=<\/span> uint16<\/span>(<\/span>0<\/span>)<\/span>\n\nbuf<\/span> :=<\/span> bytes<\/span>.<\/span>NewBuffer<\/span>(<\/span>ApplicationData<\/span>[<\/span>:<\/span>2<\/span>])<\/span>\nbuf2<\/span> :=<\/span> bytes<\/span>.<\/span>NewBuffer<\/span>(<\/span>ApplicationData<\/span>[<\/span>2<\/span>:<\/span>4<\/span>])<\/span>\nbinary<\/span>.<\/span>Read<\/span>(<\/span>buf<\/span>,<\/span> binary<\/span>.<\/span>BigEndian<\/span>,<\/span> &<\/span>FrameNumber<\/span>)<\/span>\nbinary<\/span>.<\/span>Read<\/span>(<\/span>buf2<\/span>,<\/span> binary<\/span>.<\/span>BigEndian<\/span>,<\/span> &<\/span>CurrentChunk<\/span>)<\/span>\n\n\/\/ does stuff with ApplicationData[4:]<\/span><\/code><\/pre><\/figure>\n\n
      Seems simple enough. I wrote a small Rust struct<\/code> that could chunk up a\nslice of bytes into 1024-byte vectors that fit this format:<\/p>\n\n
      struct<\/span> FrameChunker<\/span><<\/span>'a<\/span>><\/span> {<\/span>\n    inner<\/span>:<\/span> &<\/span>'a<\/span> [<\/span>u8<\/span>],<\/span> \/\/ the data to send<\/span>\n    frame_no<\/span>:<\/span> u16<\/span>,<\/span> \/\/ frame number<\/span>\n    seq_no<\/span>:<\/span> u16<\/span> \/\/ sequence number<\/span>\n}<\/span>\n\nimpl<\/span><<\/span>'a<\/span>><\/span> FrameChunker<\/span><<\/span>'a<\/span>><\/span> {<\/span>\n    \/\/ constructor emitted for brevity<\/span>\n\n    \/\/ get a new 1024 (or less)-byte chunk to send<\/span>\n    fn<\/span> next_chunk<\/span>(<\/span>&<\/span>mut<\/span> self<\/span>)<\/span> -><\/span> Vec<\/span><<\/span>u8<\/span>><\/span> {<\/span>\n        let<\/span> mut<\/span> ret<\/span> =<\/span> Vec<\/span>::<\/span>with_capacity<\/span>(<\/span>1024<\/span>);<\/span>\n        let<\/span> (<\/span>remaining<\/span>,<\/span> last<\/span>)<\/span> =<\/span> if<\/span> self<\/span>.inner<\/span>.len<\/span>()<\/span> ><\/span> 1020<\/span> {<\/span>\n            (<\/span>1020<\/span>,<\/span> false<\/span>)<\/span>\n        }<\/span>\n        else<\/span> {<\/span>\n            (<\/span>self<\/span>.inner<\/span>.len<\/span>(),<\/span> true<\/span>)<\/span>\n        };<\/span>\n        \/\/ this is from the `byteorder` crate's `WriteBytesExt` trait<\/span>\n        ret<\/span>.write_u16<\/span>::<\/span><<\/span>BigEndian<\/span>><\/span>(<\/span>self<\/span>.frame_no<\/span>)<\/span>.unwrap<\/span>();<\/span>\n        ret<\/span>.write_u16<\/span>::<\/span><<\/span>BigEndian<\/span>><\/span>(<\/span>self<\/span>.seq_no<\/span>)<\/span>.unwrap<\/span>();<\/span>\n        ret<\/span>.extend<\/span>(<\/span>&<\/span>self<\/span>.inner<\/span>[<\/span>..<\/span>remaining<\/span>]);<\/span>\n        self<\/span>.inner<\/span> =<\/span> &<\/span>self<\/span>.inner<\/span>[<\/span>remaining<\/span>..<\/span>];<\/span>\n        self<\/span>.seq_no<\/span> +=<\/span> 1<\/span>;<\/span>\n        ret<\/span>\n    }<\/span>\n\n    \/\/ returns true if we're done transmitting the current frame;<\/span>\n    \/\/ used to know when to send the next one<\/span>\n    fn<\/span> is_empty<\/span>(<\/span>&<\/span>self<\/span>)<\/span> -><\/span> bool<\/span> {<\/span>\n        self<\/span>.inner<\/span>.is_empty<\/span>()<\/span>\n    }<\/span>\n}<\/span><\/code><\/pre><\/figure>\n\n
      I then made a little 1920\u00d71080 all white JPEG in GIMP, wrote it to a file, and\nwrote some code to send out UDP multicast packets in the format the receiver\n(and de-ip-hdmi<\/code>) would expect:<\/p>\n\n
      \/\/ The magic IPv4 address for the multicast group the transmitter would send<\/span>\n\/\/ to.<\/span>\nconst<\/span> MAGIC_ADDRESS<\/span>:<\/span> Ipv4Addr<\/span> =<\/span> Ipv4Addr<\/span>::<\/span>new<\/span>(<\/span>226<\/span>,<\/span> 2<\/span>,<\/span> 2<\/span>,<\/span> 2<\/span>);<\/span>\n\nfn<\/span> main<\/span>()<\/span> {<\/span>\n    \/\/ load the test image data in at compile-time<\/span>\n    let<\/span> test_data<\/span> =<\/span> include_bytes!<\/span>(<\/span>\"..\/white.mjpeg\"<\/span>);<\/span>\n\n    \/\/ make a UDP socket for sending<\/span>\n    \/\/ note: this requires creating an interface with this address<\/span>\n    let<\/span> mjpeg<\/span> =<\/span> UdpSocket<\/span>::<\/span>bind<\/span>(<\/span>\"192.168.168.55:2068\"<\/span>)<\/span>.unwrap<\/span>();<\/span>\n    \/\/ destination address:port for video picture data<\/span>\n    let<\/span> mjpeg_dest<\/span>:<\/span> SocketAddr<\/span> =<\/span> \"226.2.2.2:2068\"<\/span>.parse<\/span>()<\/span>.unwrap<\/span>();<\/span>\n\n    \/\/ join the multicast group<\/span>\n    mjpeg<\/span>.join_multicast_v4<\/span>(<\/span>&<\/span>MAGIC_ADDRESS<\/span>,<\/span> &<\/span>\"192.168.168.55\"<\/span>.parse<\/span>()<\/span>.unwrap<\/span>())<\/span>.unwrap<\/span>();<\/span>\n\n    \/\/ current frame number<\/span>\n    let<\/span> mut<\/span> frame_no<\/span> =<\/span> 0<\/span>;<\/span>\n    loop<\/span> {<\/span>\n        let<\/span> mut<\/span> chonker<\/span> =<\/span> FrameChunker<\/span>::<\/span>new<\/span>(<\/span>frame_no<\/span>,<\/span> image<\/span>);<\/span>\n        while<\/span> !<\/span>chonker<\/span>.is_empty<\/span>()<\/span> {<\/span>\n            let<\/span> buf<\/span> =<\/span> chonker<\/span>.next_chunk<\/span>();<\/span>\n            mjpeg<\/span>.send_to<\/span>(<\/span>&<\/span>buf<\/span>,<\/span> mjpeg_dest<\/span>)<\/span>.unwrap<\/span>();<\/span>\n        }<\/span>\n        frame_no<\/span> +=<\/span> 1<\/span>;<\/span>\n\n        ::<\/span>std<\/span>::<\/span>thread<\/span>::<\/span>sleep_ms<\/span>(<\/span>33<\/span>);<\/span>\n    }<\/span>\n}<\/span><\/code><\/pre><\/figure>\n\n
      $ sudo ip link add link enp5s0f3u1u1 name showtime0 type vlan id 1024\n$ sudo ip link set dev showtime0 address 00:0b:78:00:60:01\n$ sudo ip addr add 192.168.168.55\/32 dev showtime0\n<\/code><\/pre><\/div><\/div>\n\n
      With much anticipation I then ran the code for the first time, with de-ip-hdmi<\/code>\nrunning in parallel \u2013 and got\u2026nothing.<\/p>\n\n
      Adventures in bitshifting<\/h3>\n\n
      Turns out I forgot something else in the packet format: a way to signal the\nlast chunk in a series of chunks for a frame. Going back to de-ip-hdmi<\/code>:<\/p>\n\n
      if<\/span> uint16<\/span>(<\/span>^<\/span>(<\/span>CurrentChunk<\/span> >><\/span> 15<\/span>))<\/span> ==<\/span> 65534<\/span> {<\/span>\n\t\/\/ Flush the frame to output<\/span>\n\t\/\/ [code snipped]<\/span>\n\n\tCurrentPacket<\/span> =<\/span> Frame<\/span>{}<\/span>\n\tCurrentPacket<\/span>.<\/span>Data<\/span> =<\/span> make<\/span>([]<\/span>byte<\/span>,<\/span> 0<\/span>)<\/span>\n\tCurrentPacket<\/span>.<\/span>FrameID<\/span> =<\/span> 0<\/span>\n\tCurrentPacket<\/span>.<\/span>LastChunk<\/span> =<\/span> 0<\/span>\n}<\/span>    <\/code><\/pre><\/figure>\n\n
      What the heck is uint16(^(CurrentChunk >> 15)) == 65534<\/code> doing? Let\u2019s break\nthat down:<\/p>\n\n
      I added a suitable network interface for the sender to use (the actual flat networking\nsetup uses VLAN<\/a>s for the HDMI\ntraffic, but I found out that if you just want to test then adding a loopback interface also\nworks):<\/p>\n\n
I\u2019m not a cryptographer, so this was all somewhat new to me! I was used to signatures being a hash<\/a>\nof the original message (i.e. you\u2019d send the plaintext, and then sign(hash(plaintext))<\/code> along with it), which is usually done\nso that you can sign messages longer than the size of your keys<\/a>.\nIn this case, they\u2019ve put the whole<\/em> message inside the signature to save space on the barcode, meaning you need the public keys to read the message at all.<\/p>\n\n
Android Studio also has excellent support for doing renames across an entire codebase at once, so after a long afternoon\npicking things apart it quickly started to take shape and our obfuscated code began to look something like the original source code\nmight have looked7<\/a><\/sup>.<\/p>\n\n
Mmm yes, I knew exactly what they meant when they named their class C2496p<\/code>. Of course! We just need to trace the execution\nof void mo1410a()<\/code> and then we\u2019ll figure it all out!6<\/a><\/sup><\/p>\n\n