Compare commits
2 commits
443347cad6
...
1f7bffc184
| Author | SHA1 | Date | |
|---|---|---|---|
 saji
|
1f7bffc184 | ||
|
saji
|
d540ca52eb |
|
|
@ -19,7 +19,7 @@
|
|||
<link rel="stylesheet" href="{% getBundleFileUrl "css" %}">
|
||||
<link rel="stylesheet" href="{% getBundleFileUrl "css", "defer" %}">
|
||||
<script src="{% getBundleFileUrl "js" %}"></script>
|
||||
<script src="{% getBundleFileUrl "js", "module %}"></script>
|
||||
<script src="{% getBundleFileUrl "js", "module" %}"></script>
|
||||
{% getBundle "html", "head" %}
|
||||
</head>
|
||||
<body>
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
<!doctype html>
|
||||
<html lang="{{ metadata.language}}">
|
||||
<html lang="{{ metadata.language }}">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
layout: layouts/home.njk
|
||||
eleventyNavigation:
|
||||
key: Archive
|
||||
key: Posts
|
||||
order: 2
|
||||
---
|
||||
<h1>Archive</h1>
|
||||
<h1>Posts</h1>
|
||||
|
||||
{% set postslist = collections.posts %}
|
||||
{% include "postslist.njk" %}
|
||||
|
|
|
|||
34
content/blog/github-codesarch.md
Normal file
34
content/blog/github-codesarch.md
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
---
|
||||
title: Abusing regex in GitHub code search
|
||||
date: 2025-04-24
|
||||
tags:
|
||||
- short
|
||||
- cybersec
|
||||
---
|
||||
|
||||
I recently discovered that the new(ish) GitHub Code Search feature
|
||||
supports regular expressions. While dorking on the classic GitHub search
|
||||
has been documented to death by skids, I haven't seen anyone reference this yet.
|
||||
I'm sure someone is using it, since it's powerful.
|
||||
|
||||
Case in point:
|
||||
```
|
||||
/"[a-z]{4}(?: [a-z]{4}){3}"/ language:Python SMTP
|
||||
```
|
||||
|
||||
That regex is a bit tricky, but it's just matching for 4 space-separated
|
||||
groups of 4 lowercase letters. What good does that do, you might ask?
|
||||
The SMTP should be a hint - it's some kind of credential for email.
|
||||
More specifically, this is the Google app password format.
|
||||
|
||||
This search has 5k hits.
|
||||
|
||||
I think Google will still block suspicious connections, so this isn't a huge
|
||||
pwn. But I guarantee at least one of these accounts has bad opsec, so you can
|
||||
determine their location. Combined with a bit of residential proxy work... you
|
||||
get the idea.
|
||||
|
||||
GitHub should be a lot more proactive about this stuff - blocking it from
|
||||
search, blocking it from public discovery, or even blocking the commit
|
||||
itself. Most people who are posting this stuff don't know how they could do it
|
||||
better.
|
||||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
title: Reversing an image format
|
||||
date: 2025-01-15
|
||||
tags: [reverse-engineering, hacking-hikmicro]
|
||||
tags:
|
||||
- reverse-engineering
|
||||
- hacking-hikmicro
|
||||
drafts: true
|
||||
---
|
||||
|
||||
|
|
|
|||
118
content/blog/wy-60-repairs/wy-60-repairs.md
Normal file
118
content/blog/wy-60-repairs/wy-60-repairs.md
Normal file
|
|
@ -0,0 +1,118 @@
|
|||
---
|
||||
title: Repairing a WY-60 Terminal
|
||||
date: 2025-04-28
|
||||
draft: true
|
||||
---
|
||||
|
||||
# Intro
|
||||
|
||||
While doing my usual craigslist perusal, I stumbled across a listing of a Wyse
|
||||
WY-60 monochrome terminal. I don't have a proper terminal yet, and they're kinda
|
||||
cool, so I figured I would pick one up. I learned that they had more than one,
|
||||
and one of my friends also wanted one, so I left the following afternoon.
|
||||
They had 3 units in total, but one was a bit more battle-scarred than the others.
|
||||
I think the seller just wanted it gone, since he let me take it for free.
|
||||
This would be what is known in the writing industry as "foreshadowing".
|
||||
|
||||
The Wyse WY-60 was a popular terminal due to it's comparatively low cost,
|
||||
wide range of "personalities", and plenty of features. It can do 80/132 column,
|
||||
smooth scrolling with scrollback, and a bunch of other stuff I haven't figured
|
||||
out yet.
|
||||
|
||||
# Keyboard
|
||||
|
||||
The units did not come with their keyboards. These terminals used
|
||||
a 4P4C connector with a custom keyboard protocol, so we would need to make
|
||||
an adapter. Fortunately the keyboard protocol is pretty simple,
|
||||
and is documented. Before I bought the terminals, I found
|
||||
[this project](https://github.com/bryanc806/WyseBoard/blob/master/WyseBoard.ino)
|
||||
which has a PS/2 to Wyse keymap. I also found a thread on
|
||||
[geekhack](https://geekhack.org/index.php?topic=51079.0) which revealed
|
||||
some more working details.
|
||||
|
||||
I mostly left this to my friend, who, with [ps2pico](https://github.com/No0ne/ps2pico)
|
||||
as the reference, was able to bit-bang the protocol and provide USB host
|
||||
to plug a keyboard in with an OTG cable. There are some keys that don't
|
||||
map, like the function key, or the "setup" key.
|
||||
|
||||
# Impasse
|
||||
|
||||
At this point we needed to test them out. And this is where I realized that,
|
||||
despite picking the unit with the least yellowing, mine didn't work.
|
||||
I saw the cursor, and a line for the status bar, but no characters in sight:
|
||||
|
||||
image here
|
||||
|
||||
Thankfully, the scuffed one worked, so I was able to confirm that
|
||||
I could interact with it. However, the geometry was bad and there seemed
|
||||
to be some shaking in the text, meaning a power supply wasn't being stable
|
||||
or a capacitor had gone. I had one board with working digital side,
|
||||
and one with a good power/analog side. There's also a maintentance
|
||||
manual at bitsavers so I had a troubleshooting guide and repair manual.
|
||||
|
||||
There was a spot in the manual that mentioned what to do if you didn't see
|
||||
characters. Check the font RAM and this custom controller chip.
|
||||
|
||||
I (blindly) decided to replace that font RAM, desoldering it and
|
||||
adding a socket. I used the RAM from the damaged unit as a donor.
|
||||
This took a while, as I was still figuring out the best way to
|
||||
disassemble the unit. Testing it was initially challenging as
|
||||
it sits on the screen face as you take it apart.
|
||||
|
||||
Eventually, I got it back together. But we were clearly not done.
|
||||
|
||||
image here
|
||||
|
||||
At this point, I needed to probe the system while it was running
|
||||
to see if any chips were being silent.
|
||||
|
||||
I eventually came up with this setup. It's not very safe, but
|
||||
I coped by telling myself that I would only touch the system when it was off.
|
||||
That rule didn't last long. Fortunately the low voltage digital stuff
|
||||
that I care about was close to the table and far from the spooky high voltage near the
|
||||
top of the board.
|
||||
|
||||
image here
|
||||
|
||||
My next hunch was that something was wrong with the Attribute data pipeline.
|
||||
The attribute data is what determines if a character or line is large, blinking,
|
||||
reverse-color (block), or "blank". I thought that if the pin for "blank" was stuck high,
|
||||
none of the characters would not load properly. The character attributes can either be stored
|
||||
alongside the character itself, or in a separate "Attribute RAM", which is read at the same time.
|
||||
|
||||
Image of functional block diagram, showing the attribute and character data pipelines.
|
||||
|
||||
With my new test setup, I was able to find and probe pins from the underside of the board.
|
||||
One of the challenges here is that there are multiple busses, each with potentially multiple masters.
|
||||
Not only do you need to probe a data line, you also need to have a probe for whatever makes the chip
|
||||
"active", be it a chip select, or an `~OE` pin on a logic buffer nearby.
|
||||
|
||||
Image of the PCB schematic, showing the complex bus interconnect and 74-series chips.
|
||||
|
||||
I started from the font ram, then checked U20, which was the custom chip. I kept working backwards, but couldn't
|
||||
find anything that felt wrong.
|
||||
|
||||
Things took a quick turn when I noticed this while setting up a probe:
|
||||
|
||||
Image of cold solder joints.
|
||||
|
||||
Uh, guys?
|
||||
|
||||
Image of more cold joints on a different chip.
|
||||
|
||||
It can't possibly be this, right? U17 and U15 are part of character storage, and
|
||||
I did see the font RAM output non-zero, meaning it had to have rendered
|
||||
something! I quickly cleaned up the joints and powered it on. I couldn't see it
|
||||
at first, but it worked. This highlights the two styles of troubleshooting:
|
||||
|
||||
1. Hypothesis -> Solution
|
||||
2. Hypothesis -> Validate -> Solution
|
||||
|
||||
It feels pretty good to zero-shot a repair or fix, but it also can leave you with blind spots.
|
||||
In my case, I didn't want to try to probe the board while hot, but later it became necessary unless
|
||||
I just started replacing chips indiscriminately. Once I started probing, I wanted to find something that
|
||||
seemed "off" before going further. I would have noticed the character RAM eventually, if I finished my
|
||||
testing of the Attribute RAM. In this case it was easy to spot visually and so I didn't need to test it
|
||||
any further.
|
||||
|
||||
|
||||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
layout: layouts/base.njk
|
||||
title: Now
|
||||
draft: true
|
||||
eleventyNavigation:
|
||||
key: Now
|
||||
order: 4
|
||||
|
|
@ -11,14 +12,13 @@ Rate-Monotonic scheduling my life.
|
|||
|
||||
### Playing
|
||||
|
||||
- Helldivers 2 {gamepad}
|
||||
- Helldivers 2
|
||||
- Ocarina of Time Randomizer Multiworld [link](https://wiki.ootrandomizer.com/index.php?title=Multiworld)
|
||||
|
||||
### Doing
|
||||
|
||||
- Putting out fires at $dayjob {fire}
|
||||
- Bouldering!
|
||||
|
||||
## Breaking
|
||||
### Breaking
|
||||
|
||||
- Hacking together servers with [NixOS](https://nixos.org/)
|
||||
|
|
|
|||
Loading…
Reference in a new issue