2002 Toyota Highlander Mid Dome Light Access

Written 2021-01-09

Tags:Highlander Toyota DomeLight 

Access to the mid dome light on 2001-2004 Toyota Highlanders is pretty straightforward, but changing is a little tricky. Tools Needed:

Removal of the lens

There's a simple slot to place your lever on the passenger side of the lens. Insert lever into slot and leve until the lens pops down.

IMG_20210109_110430

Removed lens

Two ends of the lens have tabs holding it in.

IMG_20210109_005844

IMG_20210109_005834

Under the lens

The bulb goes horizontally(oriented left-to-right on the vehicle). The bulb is held by two springs with holes in them. If you simply push on the bulb one way or the other, the opposite spring will follow it making it difficult to remove. By using one hand to push the bulb one way to compres one spring and a stubby flathead screwdriver to compress the other spring, you can then rotate the free-end of the bulb past the spring held by the screwdriver. This photo is rotated, and a poor shot, but you can see the springs at the ends of the bulb.

IMG_20210109_005908

Replacement bulb

Model of bulb: DE3175

Dimensions of one sample of bulb:

IMG_20210109_010119

Replacement of lens

The lens may be a little tough to get back into place. I suspect it is easier to reinstall if you put it in passenger-side first.

2002 Toyota Highlander Front Dome Light Access

Written 2021-01-09

Tags:Highlander Toyota DomeLight 

The front dome light on 2001-2004 Toyota Highlanders can be a little confusing, but simple once you get it open and can see the retainment tabs. Tools Needed:

Removal of the lens

I've found the best place to lever the lens off is actually under the light switch.

IMG_20210109_110358

Why is the lens tricky to remove

We can see that two sides of the lens have plastic tabs holding it in.

IMG_20210109_005524

IMG_20210109_005522

Under the lens

The bulb goes vertically(oriented front-to-back to the vehicle), across the reflectors. The dual curved reflectors are pretty neat, but assume light is emitted from the center of the bulb in all directions, this means that a PCB LED bulb will give you a different shape to the light coming out, for better or worse.

IMG_20210109_005255

Replacement bulb

Model of bulb: 578

Dimensions of one sample of bulb:

578 bulb length

Detecting changes to kernel registers Linux/MIPS

Written 2020-12-31

Tags:Interrupt MIPS Exception Linux 

The MIPS processor exception handling sequence uses two reserved general-purpose registers, k0 and k1. When the exception occurs, the core jumps to the exception handler address, then using only k0 and k1, the handler must save enough state to handle the exception.

From userspace, we can poll for changes to k0/k1, and track unique values, like so:

I'm not really sure what these numbers represent - they're only written by the Linux kernel, so they might be something interesting. They don't seem to line up with /proc/self/maps, but they also don't seem to line up with /proc/iomem.

ALSR function pointer addresses for PRNG seeding

Written 2020-12-26

Tags:ASLR PRNG C 

On a recent /r/c_programming post, someone noticed that srand(time(NULL)) would duplicate libc random number generator initialization whenever two programs ran it within the same second. /u/jujijengo commented that you could instead use srand(time(NULL) ^ malloc ^ printf), which on ASLR-aware operating systems should throw in some bits related to the addresses of dynamically linked functions like malloc and printf. I thought this was a pretty slick idea, but something bothered me about using two functions that could be in the same library.

As an aside, you should always evaluate random number generators against your application requirements. libc srand()/rand() aren't great, but today we'll focus only on reducing the number of repeated seeds at the same time on ASLR-aware operating systems.

On 64-bit ASLR systems, the address of a library should have at least a few random bits (How many? How random? Up to the OS and address space) that tend to vary between program executions, so xoring them with the time should help.

But, the addresses of malloc and printf usually aren't independently random - at least on Debian Buster, they're both provided by GNU libc. Effectively, the contiguous pages of libc's code will be placed at a random location, but the following are static across process creations, even with ASLR:

Test Program

A simple C program with the following snippet of code can be executed many times to output ASLR-based libc function addresses:

printf("%p %p %" PRIxPTR" %" PRIiPTR "\n",malloc, printf, (uintptr_t)malloc^(uintptr_t)printf, (intptr_t)((uintptr_t)malloc - (uintptr_t)printf));

Results on Debian Buster on AMD64

Here are some statistics on 100k runs on a 64-bit Debian Buster Intel laptop from the snippet above:
number of samples in run:100000
unique locations of malloc:99981
unique locations of printf:99981
unique results of malloc xor printf:70
up to 10 most common counts and offsets between malloc and printf:
 100000 179696
up to 10 most common counts and values(hex) of malloc xor printf:
   3156 7c630
   3222 1d4630
   6185 74630
   6239 d4630
   6243 6c630
   6324 5c630
   6334 3c630
  12409 2c630
  12457 54630
  12479 34630

Offset between malloc and printf is probably fixed

This makes sense because if malloc and printf are in the same text section of libc, we would expect the dynamic linker would always locate into contiguous memory pages.

ASLR can repeat libc load addresses on a 64-bit machine

"ASLR: How Robust is the Randomness?" by Ganz and Peisert suggests 64-bit ASLR can use 48-bits of random virtual address, which seems reasonable, since it must be less than 64-log2(PAGE_SIZE), which is 52 bits on this system. Also, at least on this system, the upper four bits of text addresses in libc appear to always be 0x7.

But even assuming the ASLR implementation uses a good PRNG, there's still a birthday problem limitation. But none of the online birthday attack calculators I tried support computing the probability of collisions between 2^48 unique locations over 100000 samples.

Whatever the cause, we do see that over 100k program invocations, repeated addresses do occur, but rarely. It's not always 19 times per 100k, that's just what happened this run.

ASLR repeats malloc xor printf much more often than either function independently.

This makes sense to me, as any time the upper bits of both function addresses are the same, xor will zero them, and this is where most of the randomness of ASLR lives.

ASLR repeats malloc xor printf more seldom than I thought it would.

Initially I had worried was that malloc^printf would evaluate to a constant - this was not quite correct - it seems to depend on the offset between them. If malloc and printf are located in the same virtual address page, then malloc ^ printf's upper ASLR bits would always cancel to zero and the lower bits would represent only xor of the offset differences.

At least on this system, malloc and printf at around 175 kilobytes apart, so malloc ^ printf is a mix of behaviours. The upper bits are still zeroed. The lower bits still represent the xor of the offset differences. But the middle bits change whenever the upper bits of the offset differences overlap the lower bits of the page address differences.

Conclusions

Using ASLR addresses to scavenge a few noisy bits can work for simple PRNG seeding, but care must be taken that each address is independent. /u/jujijengo suggested Melissa O'Neill's approach in the PCG entropy fallback generator, which uses time(NULL) ^ current_function ^ address_of_a_stack_variable if /dev/random is not available, which should work well, since stacks and text-segments are always separately locatable by ASLR.

2002 Toyota Highlander Positive Battery Terminal Interface

Written 2020-12-20

Tags:Battery Highlander Toyota 

Recently, I replaced my car battery and alternator on my 2002 Toyota Highlander. While doing so, I noticed that the positive battery terminal was fairly corroded and should be replaced before failure.

battery terminal adapter

Yep, that's pretty chunky, time for a new one. But the local autoparts store didn't have quite the right replacement. At least in the US, it's common to use SAE top-posts, where the positive terminal is a little larger than the negative(also true of JIS, but this car uses SAE top posts). Here's a rough diagram of the component I need to replace:

battery terminal adapter diagram

The key measurements are:

What's available:

I ordered the part from Amazon, and it works great!

Older