Electronics > Microcontrollers

Accessing Hidden Diagnostics in Prog Memory ATMega1280?

(1/2) > >>

Rjc987:
Hi guys! Im working on a biotek spectrophotometer that uses a atmega1280, 1281 and 164p (1280 seems to be the main micro) trying to track down some errors which aren’t documented in the manual and decided to try to get a better understanding of the machine so I hooked up mplab via JTAG through an mplab snap and in the process of stepping through the program in debug mode, I realized a huge chunk of the program memory is dedicated to a factory setup and debug feature, with menu options in ascii (like “test mode” “select desired command character” “toggle test mode on/off ‘O’, etc. See images below - these are just 2 pages of about 15 pages of menu).

These detailed and advanced onboard diagnostic tools would be a HUGE help as currently the only obd available is a very basic self test in the windows software but I have no idea where to begin or how to figure out what I need to do to access any of it. Does anyone k have any idea how this works? Thanks!

Berni:
You run the hex dump trough a disassembler to convert it back to assembler code and spend many hours staring at the huge assembler mess until you figure out how it works.

Usually the best hint to start with is looking for memory references to those strings.

mjs:
Looks like you've got the flash dump, which is sometimes the hard part requiring glitching and other tricks. The next usual step is to hit it with IDA Pro (€€€) or Ghidra (paid for by generous US taxpayers.

I've used Ghidra, but the learning curve is rather steep. It's not just a disassembler/decompiler, but rather a full toolkit for reverse engineering binaries. On the other hand there are now a lot of youtube videos on how to use it.

Usually hidden menus and how to access them reveal themselves from the source code rather fast - you start from the interesting strings, check which functions access those. Then do the same for button / serial IO - which may often fiddle data through ISRs. After this the solution often awaits you very close to the place where these paths meet in the call graph.

Basic code reverse engineering is a very useful skill when dealing with existing stuff - and also while developing new, I've found out!

T3sl4co1l:
Well, that's a damn sight easier than they could've made it.

Your first boon: they didn't lock the Flash, or encrypt it (not that there's any real-time decryption capacity to speak of on an 8-bit CPU, lol), or disable the programming port(s).

Second boon: AVR is one of the more pleasant dialects to read and understand.  Uh... if you aren't familiar with the ISA (Instruction Set Architecture), that'll be a bit of a missed point for you, understandably... but if you're familiar with any assembly, you should be able to get a good feel for it with a couple weeks' study, and if only programming generally, maybe some months.

Assuming they used most of the 1280's available program memory, you'll have a pretty good chunk of time picking out all the various subroutines, function calls, data paths... but it's by no means impenetrable.

Mind, heh, I do say this with the bias of mainly having looked at my own output (symbols included), not completely bare and scrubbed binary.  It will be quite some work to reconstruct all that, of course.

Ease of disassembly, is reasonably true for the most popular flavors of MCU; depending on age, it could've also been 8051, Z80, 68k, x86, MIPS, or a few others; and especially these days, ARM.

I'm not sure about AVR offhand, but ARM, x86 and many others are well supported by disassembly and decompilation tools such as Ghidra.  The asm might be a bit more opaque to read (particularly some of the instruction ordering say with MIPS, I think?), but the decomp is -- well, you still don't get any symbol names, but formatted C code is a far sight better than the alternatives, especially if you're not well versed in the ISA itself.  That, and the instant cross-referencing and refactoring, makes analysis so much easier.

As for just trying to figure out the interested function straightaway, the most likely candidates would be a serial port somewhere, or jumpers or dip switches to activate a service mode, or some password to enter on the main menu, or some sequence of button presses to unlock a hidden menu, or etc.  Lots of possibilities of course.  If it's a password, you might find a string somewhere in .data (usually near top of Flash), or .progmem (usually near the bottom).  It might also be checked by a sequence of compare instructions, or alternating loads and compares, or a limited crypto sort of function might be employed that uses a lot of eor instructions which can give some direction on where to look (but mind that eor rn, rn is commonly used as ldi rn, 0 shorthand, depending on compiler version or asm author, so it's not very specific).  Snooping around relevant code sections (be careful to try and spot pointers and addresses, try to backtrack along code and data paths; very hard in raw hex, easier disassembled) may lead you to a data path or state machine (esp. to do with menus?) that allows access.

If it's via serial port or whatever, it might be tricky to figure out, just because they needn't put any feedback in; it could be a binary comm channel for example, without even a terminal echo to tell what the baud rate is.  If you're lucky, it's just wide open, plain text, it blinks out some data on startup, the baud is standard, and they have a service menu and everything right at your fingertips.

Tim

abyrvalg:
OP, would you mind posting the dump here so we’ll take a look?

Navigation

[0] Message Index

[#] Next page