How to debug application without binaries

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use AVR Studio and JTAGICE. Let's assume I have a programmed microcontroller, which I wish to debug. The software in microcontroller consists of two parts "“ bootloader and application code, flashed separately by bootloader. Obviously I don't have sources, nor binaries of both joined together. So I want to start debugging, without any project in AVR Studio "“ I just want to see assembler instructions executed by processor. But without opened project I cannot start debug session, and when I open bootloader or application project microcontroller FLASH memory will be reprogrammed before debug session will start "“ so bootloader code, or application code will be erased. How to solve this problem?
TIA.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use ISP to read out the .hex then in Studio File-FileOpen... the .hex file at which point it will offer to create a .aps file. You are then shown the dialog where you can select platform and advice. Set platform to "JTAGICE" and the device to the right model of AVR.

Obviously this is going to be uncommmented Asm debug only which can be "fun". More so if the source was C in which case the code can be very "dry" and full of stack frame nonsense making it more difficult to follow.

I guess you have a legal right to reverse engineer this code?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it’s my code. It just consists of two separated applications – main app and bootloader. Your method will probably work, but I thought about something simpler – like a magic option – don’t update FLASH when starting debug session.
And BTW, in my country (Poland) reverse engineering is legal. In fact it is the only way to know how some closed protocols work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

In fact it is the only way to know how some closed protocols work.

Presumably they are "closed" because someone does not want you to know how they work - usually because they charge money to access the details normally so you are stealing their revenue by doing it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It’s a discussion about ethics. If they want to keep something for them, they can patent it. I don’t think that something should be prohibited, just because somebody wants to keep something closed. But as I said, reverse engineering in my country is absolutely legal, so for example if a company keeps protocol closed, I’m allowed to reverse engineer it, and write my own program based on obtained information. I think that more or less it works exactly in the same way in many countries. For example linux developers – in many cases the only way to write a driver for device is to reverse engineer the original closed source driver. Because lunux developers are spread all over the world, I think that in many countries it is legal.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TFrancuz wrote:
Yes, it’s my code. It just consists of two separated applications – main app and bootloader. Your method will probably work, but I thought about something simpler – like a magic option – don’t update FLASH when starting debug session.
And BTW, in my country (Poland) reverse engineering is legal. In fact it is the only way to know how some closed protocols work.

If it is your code, you have the source code.

You can debug the application in the regular way. It just happens that the JTAGICE loads the application rather than the bootloader.

You can always merge the sources of bootloader and application if you want. You just need to mangle the names of any duplicated identifiers.

OTOH, if you are seeking to debug compiled code that does not belong to you. Good Luck. If the original owner was wise, she would have used an encrypted bootloader and application and used lock bits and fuses. ------------ just to make your job more challenging!

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I said, I have two separated applications, main app, and bootloader, again – to separated codes, two projects. The binaries are merged only in microcontroller FLASH memory. I want to debug the part of bootloader responsible for calculating application’s CRC and launching it – that’s why I need the app in memory during bootloader debugging. That’s all.
And it is not that simple to merge the source codes. Besides name mangling, I need two separate .text sections, .bss etc. If you know how to easy do it, just share your knowledge with us. And of course, if the chip has been locked I wouldn’t be able to read it and debug, and it is obviously not my problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not use the bootloader's programming mechanism to deliver the code into the app part of the flash? (that's what it's designed for after all!) That way you can symbolically debug the ELF of the bootloder.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wikipedia wrote:
Article 6 of the 1991 EU Computer Programs Directive allows reverse engineering for the purposes of interoperability, but prohibits it for the purposes of creating a competing product [...]

TFrancuz example of a Lunix driver sounds like "interoperability" to me..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I want to debug the part of bootloader responsible for calculating application’s CRC and launching it – that’s why I need the app in memory during bootloader debugging.

You really do not care what the application is. You are simply debugging the bootloader 'application' that load some arbitrary gobbledygook into FLASH memory.

You can verify the gobbledygook via regular ISP. You can verify the CRC in the debugger. You generally debug a CRC algorithm via an ordinary PC console app.

You could even get the bootloader to write the CRC into EEPROM. This would involve no debugging at all.

David.