Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain PAL + DSCContext #68

Open
brandonros opened this issue Sep 22, 2024 · 3 comments
Open

Explain PAL + DSCContext #68

brandonros opened this issue Sep 22, 2024 · 3 comments

Comments

@brandonros
Copy link

brandonros commented Sep 22, 2024

I see this is hidden by default/off by default:

https://github.com/jglim/CaesarSuite/blob/main/Caesar/Diogenes/Forms/MainForm.Designer.cs#L375-L376

I seem it goes to this:

https://github.com/jglim/CaesarSuite/blob/main/Caesar/Caesar/DSCContext.cs

I also see your comment here:

jglim/UnlockECU#13 (comment)

Can you help clarify if this is true:

Some CBFs do not have a SecurityAccess DLL or JAR and instead they have a custom scripting language inside of them where seed/key can be accessed?

You did a great job being able to dump and extract properly these PAL files. I just wanted to better understand their structure. How can I execute/run them or see their logic/decompile their instruction set?

It isn't clear to me if when CaesarSuite runs a diagnostic job if it can run this custom language from the interpreter or if it skips over it?

@jglim
Copy link
Owner

jglim commented Sep 22, 2024

Some CBFs do not have a SecurityAccess DLL or JAR and instead they have a custom scripting language inside of them where seed/key can be accessed?

Yes that's true. No DLLs are embedded in the CBF for both of those targets. They are capable of unlocking the ECU for flashing the firmware, and the keys are generated through their own scripting language.

How can I execute/run them or see their logic/decompile their instruction set?

Vediamo is probably the easiest way to get that done. Some discussion in the issue here: jglim/UnlockECU#12 , there's also an experimental DLL hook to trace the instructions as they are getting executed.

It isn't clear to me if when CaesarSuite runs a diagnostic job if it can run this custom language from the interpreter or if it skips over it?

I've reversed the interpreter far enough to build a partially-functional interpreter. However this is only available in the v2 branch, which is a significant rewrite and is missing a lot of functionality from the current version.

At this point, there are enough implemented opcodes for the IC204 on my bench to be flashed successfully, purely using the logic from the CBF file, though I am far from confident enough to recommend it for general use.

@brandonros
Copy link
Author

Thank you. I need to run through this. Let me see if I can help/test.

Where might I find this experimental hook trace DLL that logs executed instructions?

@brandonros
Copy link
Author

brandonros commented Sep 22, 2024

image

The given key '264' was not present in the dictionary on InterpreterMemory GetTrackedObjectAtAddress

Looks like the 0x2d7 Unk2 instruction needs a touch more work:

image

Let me see if I can find what it is.

This might be it as well:

Unhandled opcode 0x0094 at cycle 1501

image

Let me see if I can find all the undefined opcodes from this CBF script I have

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants