I've dabbled enough in some ECU code to know how much more is required.
The coding is written in bytes which you can identify tables and maps (maps are 3D tables) using software like WinOLS. This is the level of identifying and tweaking what is there. It's slow and painful to identify and edit. It's almost like floundering around in the dark.
The coding is created using other software to create an instruction tree that is literally a chain of logic statements and look-up tables.
It is possible to reverse-engineer the code back to the original instruction trees, but that requires knowing what it was written in and several other difficult things. The electrical hardware (chipset) and the manufacturers documentation for the chipset can be a starting point for this.
There was a really good article around the VW emissions scandal where someone was able to reverse engineer the code to work out what the test mode was, how it was triggered and what it did to the engine coding.
This might be referring to the same guy, I remember the idle RPM being discussed:
32C3: Dieselgate — Inside The VW’s ECU
Ultimately I think you're better off being able to reverse engineer the code back to the flow-charts and lookup tables, then modify those as required.