Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    vincentdupaquis
    @vincentdupaquis
    Hello guys !
    I would have 2 questions about rainbow
    1st : Why don't all ARM registers are listed in INTERNAL_REGS ?
    2nd : Where can I find the hook which is responsible for generating the leakage (presumably the hamming distance of changing registers) ?
    yhql
    @yhql
    Hi !
    n° 1 Only the registers that most commonly affect execution are listed (in order to wipe them when resetting execution). Which ones are you thinking of ? We could add those
    vincentdupaquis
    @vincentdupaquis
    The registers I do not see are r8-r12. Those can be very easily used from Cortex-M3, and although are a pain in the a.. to use on Cortex-M0 can still be on this core.
    The xPSR and SP is also missing, why ?
    Regarding the hooks on arm, why not simply monitoring the hamming distance of all registers (from r0-> r15), instead of trying to guess which are used ? is it faster ?
    BTW thanks for the pointers on the hooks !
    yhql
    @yhql
    No particular reason for not having those (r8-r12, SP, ...) , we can add them
    Capstone allows to know exactly what registers are used in an instruction. Using this, we don't need to impose a leakage model (hamming distance) to the user. Instead, we can leak only the relevant information and the trace can be processed later on to match the user's leakage function
    vincentdupaquis
    @vincentdupaquis
    Does capstone include in the registers list the PC ?
    Another question : Is there a way to have an execution trace (trace of all executed opcodes) ?
    I would be interrested in having this from time to time (not on a regular basis, I suspect it would generate a huge amount of data and possibly slow-down the simulation very much ...).
    yhql
    @yhql
    I don't think the PC is included, no
    You can get an execution trace by switching off the sidechannel mode and setting e.trace_regs and e.mem_trace to True
    vincentdupaquis
    @vincentdupaquis
    I'll have a look at all this, thanks !
    yhql
    @yhql
    there's also a basic breakpoint support through e.add_bkpt( address )
    vincentdupaquis
    @vincentdupaquis
    I saw this, although I did not try to use it
    In fact, and to sum-up, to me the tool is really brilliant. The only dark point remains that when you start(), unless you know roughly the number of ins. or the max timing, there is no easy way not to execute garbage.
    This is where I had most troubles, I had to instrument the code in a way I could know that after the execution, I would go through a given address.
    Without no deep understanding on how the processor/compiler works, no way you can do this, unless you are lucky, as in your aes.bin example.
    Exit points are always unique, and at the end of the function segment, therefore no need to set the "end", or "count" param
    Anyhow, I'll pursue with it and thanks for the support !
    vincentdupaquis
    @vincentdupaquis
    Just to give you an example, I did this way :

    void attribute ((noinline)) TestSCAAESEnd(uint32_t ret)
    {
    (void)ret;
    asm("nop");
    asm("nop");
    asm("nop");
    }

    void attribute ((noinline)) TOC_AES_Seed(uint32_t Seed)
    {
    TOC_lfsr_seed(Seed);
    }

    void attribute ((noinline)) TOC_AES_Adresses(int Element)
    {
    void
    ret;
    switch (Element)
    {
    case 0:
    ret = (void *)Key;
    break;

        case 1:
            ret = (void *)DataIn;
            break;
    
        case 2:
            ret = (void *)DataOut;
            break;
    
        default:
            ret = (void *)0xDEADBEEF;
            break;
    }
    TestSCAAESEnd((uint32_t)ret);
    
    return ret;

    }

    TOC_AES_status_t attribute ((noinline)) TestSCAAESSetKey(void)
    {
    TOC_AES_status_t ret;

    ret = TOC_AES_set_key(...);
    TestSCAAESEnd((uint32_t)ret);
    
    return ret;

    }

    Calling TOC_AES_Adresses() by asking the end to be the address of TestSCAAESEnd()
    yhql
    @yhql
    Thanks for the info ! Indeed this is sometimes more reversing than just tracing
    vincentdupaquis
    @vincentdupaquis
    Sorry for the black inserts, tried to remove them but no way ;-)
    yhql
    @yhql
    One trick that I've seen Miasm authors use for example, is to push some special address on the stack (for x86) or into the 'lr' register, and specify this address as 'end' during the start()
    It's clearer to see when the execution reached its 'normal' end this way
    vincentdupaquis
    @vincentdupaquis
    it's a way, indeed.
    vincentdupaquis
    @vincentdupaquis
    Hello, About the trace, how can I have an alignement between the trace obtained and the timing ?
    What I mean is that I am looking for an information allowing to know the code location of a leakage, the link between both being the time (eg. an instruction generates a leakage at cycle 1000, executing a xor r0,r1 for instance), how can I know the pc at the moment the leakage appears ?
    yhql
    @yhql
    Hi, you can use the dedicated viewer to inspect that :
    from rainbow.utils.plot import viewer
    viewer(e.sca_address_trace, e.sca_values_trace)
    otherwire, you can check what instruction was executed and at which address juste by doing e.sca_address_trace[1000]
    vincentdupaquis
    @vincentdupaquis
    I had both memory accesses and intructions in the trace, keeping only instructions is exactly what I wanted to do :-)
    Thanks for your proposals !
    ddddavidee
    @ddddavidee
    hi @yhql I'm here